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ABSTHACT 

This thesis reports on the design and implementation of 
a simulation of the Signal Processor Interface to the 
AN/SPY-1A Phased Array Radar Controller, Inherent to the 
simulation is the development of a representative time 
sensitive database of the targeting environment. The 
programming language Ada was utilized as a program develop- 
ment language in the design for the database. The developed 
Target Database utilizes the 20 mega-byte REMEX Data 
Warehouse 3200 memory storage unit. The simulation of the 
Signal Processor Interface will allow real time testing of 
the Naval Postgraduate School's AN/SPY-1A Radar Controller 
System Model. 
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I. IH TROD UCTION 



a. BaCKGBOOND 

Tha AEGIS System is the Navys multi-faceted 
shipboard weapcn ccntrol, decision making, and surveil- 
lance system. The engineering model began testing on the 
"Norton Sound" in 1977 and the AEGIS System joined the Fleet 
on board the "Ticonderoga" in 1982. To date, the AEGIS 
System represents the newest fielded technology in the 
Fleet and possibly in the world. Since every design 

effort must at some time in the design determine what the 
target hardware will be for the system, the result is that 
all "new systems" do not in fact utilize the most current 
electronic advances. In addition, the further design, 
testing, and linking of the many separately developed 
and tested modules further increases this unaviodable hard- 
ware gap. In the case of the AEGIS System, this is 
particularly true since we have seen a technological revo- 
lution cccur during it*s development. The Large Scale 
Integrated Circuits (LSI) , and now the Very Largs Scale 
Ingrated Circuits (VLSI) are common in our off-the-shelf 
technology. The Naval Postgraduate School AEGIS Modeling 
Group has been investigating the use of new off-the-shelf 
VLSI technology that could provide significant savings in 
money and space while still fulfilling the system require- 
ments of the AEGIS system. The AEGIS Modeling Group 

decided early in their study and emulative modeling 
to choose the AN/SPY-1A Phased Array Radar Controller as a 
modeling subset of the AEGIS system. The SPY-1 A Radar 
represents a sufficiently difficult and real time 
sensitive module of the AEGIS system such that if it 
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can be succassfully eniulated, then it should be 
possible tc similarly build the other modules comprising the 
total AEGIS system. 

The AN/SPY-1A is a complicated and extensive system in 
its' cwn right. The two primary modules of the SPY-1A Radar 
Contrcller are the Radar Scheduler and the Track Processor. 
Previous thesis work has been done to model these two 
modules by Grant [Ref, 1] and Cech [Ref, 2] respectively. 
In addition, the two systems that depend on the AN/SPY-1 A 
for data - the Weapon Control System (WCS) and the Command 
and Decision System (CD) - have been simulated by Boone 
[Ref. 3] in his thesis. The Signal Processor mcdul-e is 
another module to be simulated such that the NPS SPY-1A 
Model subset can be fully interfaced and tested for real 
time capability and logical functioning. The initial 
design, development, and target environment simulation of 
the SPY-1A Signal Processor Interface is the intent of this 
thesis. 

B. DISCLAIMER 

Many terms used in this thesis are registered trademarks 
of commercial products. Rather than attempting to cite each 
individual cccurrance of a trademark, all registered trade- 
marks appearing in this thesis will be listed below, 
following the firm holding the trademark. 

Intel Corporation, Santa Clara, California: 

Intel, Intel 8086, iSBC 86/12A, MULTIBOS 

Digital Research Corporation, Pacific Grove, California: 
CP/M, CF/M-86, PL/I-86, PL/I-80, ED, RASM-86, LINK86, 

DDT-86 

EX_CEIL_C Corporation, Irvine, California: 



REMEX Data Warehouse 



MicroPro International, San Rafael, California: 
Wordstar 

Department of Defense, Washington D.C.; 

Ada 

Micropolis Corporation, Chatsworth, California: 
Micrcpolis 

Lear Siegler, Inc., Anahiem, California: 

ADM- 3 A 



C. POBPCSE OF THIS THESIS 

The troad direction of the Signal Processor simulation 
is threefold: 

1. Emulate the SPY_1A Signal Processor using the Rsmex 
Data Warehouse (a 20 megabyte fixed Winchester tech- 
nology disk system) . 

2. Ee able to emulate the signal processor functions to 
provide a real time test environment for the SPY-1A 
Model. 

3. Ee able to use the simulation tc test the logic of 
the NFS SPY-1 A Model . 

These bread objectives were further subdivided into tasks to 
develcp a target database module and two system testing 
modules. The first system testing module will emulate the 
hostile environment cf targets utilizing a pr e-developed 
target database while the WPS SPY-1 A Model is being run/ 
tested fer real time operations. This model is designed to 
respond as quickly as possible to a dwell command from the 
Radar scheduler Module with an appropriate data output to 
the Track Processor Module, to allow an accurate test of the 
speed of the overall SPY- 1A Model. This design will be 
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herein referred to as the "Static Model". The second system 
will be used to test the logic of the internal SFY-1A 
modules, and will not be constrained to real time run 
requirements. It will display a target environment as it 
developes and changes over time, and allows the user to 
initiate and change the environment as he desires. This 
design will be herein referred to as the "Dynamic Model". 
The tasks fcr each of the Modules are as follows: 



TARGET DATABASE: 

1. Create targets. 

2. Develop target tracks and record those target loca- 
tions on the respective track at descrete time inter- 
vals in the database. 

3. Modify and Delete targets and target dadta on the 
database . 

STATIC Model: 

1. Interface database access with NPS SPY_1A Model 

2. Monitor the I/O interface during testing without 
detracting from the real time environment 

DYNAMIC Model: 

1. Allow interactive changes to be made to the database 
during runtime 

2. display the tracks in the database as the simulation 
runs 

The scope of this thesis extends primarily to the Target 
Database and Static Model development and implimentation, 
although the overall design structure is such that the 
Dynamic Model can encompass and utilize the modules devel- 
oped herein. 



13 



D. 



THESIS OSGiNIZATICN 



The thesis is organized into four chapters. The computer 
code developed to iiplement the system is contained in the 
following appendices. The first chapter covers the back- 
ground of the Aegis Project at the Naval Postgraduate 
School, . the basic direction for this thesis, and thesis 
organization. The second chapter covers the design of the 
Signal Processor Interface Module. It will discuss the 
overall considerations for the design, the interfaces 
nsccessary between the Signal Processor and the ether 
modules previously developed, and the specific design for 
the Target Database and Static Model. The programming 
language Ada was utilized as a Program Design language (PDL) 
in the development of a design for the Target Database and a 
Dynamic Model. The third chapter will discuss the implemen- 
tation cf the design for the Signal Processor Interface 
Module. Translation considerations when Ada is used as a 
PDL and the implementation language is PL/I are highlighted. 
The modules that make up the Target Database and the Static 
model are discussed in detail. Finally, Chapter four 
presents some conclusions on the work involved in the design 
and implementation of the Signal Processor Interface Module 
as it is now, how it might be utilized and changed by future 
Aegis Group members, and what the nexr logical steps should 
be toward the complete simulation of the critical paths of 
the SPY-1A Phased Array Radar Controller. 
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II. EESI^ OP THE SIGNAL PROCESSOR SIMULATIO N 



A. OVERALL CONSIDERATIONS 



1 . De sign ing f Chan g e 



Tc provide the desired future maintainability and 
flexibility as a simulative and emulative instrument, it is 
neccesary tc design the Radar Signal Processor Simulation 
with the capability for change. The latest concepts of good 
software engineering principles explain that forseeable and 
non-f orsesable changes are sure to be applied to any soft- 
ware engineering project, but especially in those cases were 
the program being developed is being separately designed and 
implemented to become part of a larger system. To provide 
that capability, the designer and programmer must from the 
start try to separate those items that are likely tc be 
changed and use the concepts of clear documentation and 
structured programming to make it easier for the system 
users and maintainers to incorporate changes. The decisions 
that are made in modularity and implementation must be docu- 
mented tc enhance the under standabili ty of the system. As 
much as possible, the assignment of parameters and constants 
should be clustered or at least positionally standardized 
within modules to allow ease in finding them and changing 
them. The design concept of information hiding needs to be 
utilized such that enhanced versions of specific implementa- 
tions can be easily substituted without causing major 
changes throughout the other modules that constitute the 
overall design. 
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2 • Des lon i nq for 5xte n sibility 

A part of designing for change is the consideration 
of and provision for extensions to the basic design one may 
provide. It is important to consider the critical items in 
the design, and yet still allow for the addition cf ether 
modules that may provide desired functions for future users 
of the system. One way to provide this capability in a 
design is in utilization of a tree like structure that will 
allow the addition of other branches at any node of rhe 
hierarchy. In so doing, the designer offers the maximum 
flexibility in the basic design, and enhances future main- 
tainability and changability , while providing for the 
unf orseeable. 

3 . H cdula r Design 

Incorporating the design principle of modularity 
will provide the basis for both changability and extensi- 
bility. Choosing modules in the program that describe a 
concise function, and interface with each other without side 
effects will enhance the un der standability of the design and 
the resultant code. Otilizing a design methodology that 
incorporates the principles of top-down design and assists 
in the partitioning of a complex problem into intellectually 
addressable sub-problems will naturally produce good modu- 
larity. Eoochs' "Object-Oriented Design" methodology 
[Hef. 4] discussed in detail in Section II. C and Appendix E 
provides these attributes. The design of both the target 
database and static model incorporates many of these princi- 
ples limited only by the author’s designing and programming 
prowess . 
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B 



INTERFACES 



In ~h€ thesis work done by Riche and Williams [Ref. 5], 
the overall design and modular interfaces were discribed and 
defined fcr all future SPY-1A Ccnrroller Module development. 
However, since their design incorporates the development of 
all the modules, and the project at this stage of iirplemen- 
tation has only developed the most critical modules required 
to emulate a basic subset of the real SPY-1 A Radar 

Controller, the interfaces they developed are not completely 
appropriate. To interface with the dwell commands passed by 
the Radar Scheduling module [Ref. 1] and to pass feedback 
that can be understood by the Track Processor module 
[Ref. 2], the Signal Processor Module must logically incor- 
porate the Radar Output, Radar Return, and Beam 
Stabilization modules. Therefore, the interface utilized 
for input is table_58 ("Common Memory Interface between the 
Radar Scheduling and the Beam Stabilization modules") , and 
the inrerface used to output is table_8 ("Common Memory 
Interface between the Beam Stabili zazicn and the Track 
Processor modules") [Ref. 5]. Non only will xhis extension 
of the logical interface for the Signal Processor make the 
future work of interfacing the modules easier, but it makes 
the present design fcr the Signal Processor Interace Module 
easier to implement. The chosen interfaces will allow the 
signal processor model to receive and send target data in 
terms of cartesian coordinates rather than the lengthy and 
complicated codes that specifically tell the signal 
processor where to point its beams. Tables I and II show 
the respective interfaces. 
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TABLE I 

Signal Processor Output Interface 



T 



/♦ 

OWNER: AEGIS MODELLING GROUP 
DATE OF LAST UPDATE: 28 OCT 81 
MODULE TYPE: TABLE 
PURPOSE: COMMON MEMORY INTERFACE 
NAME: E TO P TABL 
♦/ 



THIS TABLE INTERFACES BETWEEN THE BEAM STABILIZATION 
PROCESS AND THE TRACK PROCESS 



declare 
1 B to P tabl 
2“x su'B s 
2 y~sub“s 
2 z"sub s 
2 face Id 
2 dwl_Idx 
2 trk num 



static external, 

fixed binfIS't 
fixed bin (1 5'i 
fixed bin(15i 
fixed bin (1 5 
fixed bin (7) 
fixed binP) 



initial (0) , 
initial (0) , 
inirial (0 i , 
initial (0) , 
initial (O'' , 
initial (0) ; 



/* END OF TABLE */ 



L 



J 



C. USE OF ADA AS A PBOGRAH DESIGH LAHGUAGE 

Grady Bcoch [Ref. 4] has proposed a software engineering 
design technique he terms "Object-Oriented Design". 
Although his chosen name for the design methodology may be 
unfortunate considering the controversy raised by the ambi- 
guous term "Object", and the pasr use of the term in refer- 
ence to the Smalltalk programming language, the design 
methodology itself works well. Using the new Department of 
Defense programming language Ada, the purpose of 
Object-Oriented Design is to produce logical, efficient, 
highly readable and understandable code rhat accurately 
reproduces the real world problem in the computer space. 
Ada is utilized as a program development language because of 
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TABLE II 

Signal Processor Input Interface 



/♦ 

OWNER: AEGIS MODELLING GHODP 
DATE OF LAST UPDATE: 2 NOV 81 
MODULE TYPE: TABLE 
PURPOSE: COMMON MEMORY INTERFACE 
NAME: E TO B TABL 
*/ " 



/* 

THIS TABLE IS THE INTERFACE BETWEEN 
AND BEAM STABILIZATION PROCESSES 
*/ 



RADAR SCHEDULING 



declare 
1 R to_B ta 
2“search 



■3 

3 

3 



3 

3 

3 

3 

3 



asxni 
elev 
■time 
4 m 
4 1 
dwl_ 
beam 
aloh 
beta 
face 
tr]c_bur 
3 zYos 
3 stab 
4 X 
4 y 
4 z 
dxl_ 
time 
4 IQ 
4 1 
beam 
alph 
beta 
face 



bl (10) 
dwls. 



static external. 



3 

3 



■3 

3 

3 

3 



s b 
s b 
idx 

purpose 

a delta cos offset 
■delta cos offset 
“assign “ 
n thru , 

_dwl 

e coords, 
stbl 
“st bl 
“stbl 
idx 

sb 
s b 

curpcse 

a. delta cos_offset 
■delta cos offset 
^assign “ 



fixed 


bin ( 




initial i 


[0) 


fix ed 


bin ( 


[I5j 


initial ( 




fixed 


bin 1 


[15) 


initial ( 


[0) 


fixed 


bin 1 


15 


initial i 


0 


fixed 


bin 


7) 


initial i 


P) 


fixed 


bin ( 


p) 


initial ( 


’O' 


fixed 


bin i 


15) 


initial i 


[0 


fixed 


bin 1 


15 


initial i 


P) 


fixed 


bin 1 


7)' 


initial ( 


p 1 


fixed 


bin (7) 


initial (0) 


fixed 


bin ( 


[15) 


initial < 


[0) 


fix ed 


bin i 


15 


initial i 


p 


fixed 


bin 1 


15 


initial i 


p) 


fixed 


bin ' 


[7) 


initial I 


p) 


fixed 


bin ( 


[15) 


initial ( 


p) 


fixed 


bin ( 


15 


initial ( 


[0 


fixed 


bin I 


71 


initial i 


p) 


fix ed 


bin ( 


15) 


initial < 


p 


fixed 


bin ( 


15 


init ial i 


p) 


fixed 


bin ( 


7) 


inirial i 


p 



/* END OF TABLE */ 



its capabilities in the production of highly structured and 
modularized algorithms. It also has the nice fea-uure of 
separating the specifications for the modules utilized in 
the design from the actual methods used for implementation 
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cf these modules, and thus provides the designer with an 
ability to postpone the implementation decisions for as long 
a time as convenient during the design phase. This feature 
was particularly important since the programming language 
FL/I-86 was going to te used for actual implementation, and 
it was intuitively felt that some design changes and conces- 
sions might have to be made even at the highest levels 

because cf the differences in the large scale data struc- 
tures provided by the two languages. 

Object-Oriented Design methodology is broken down into 
three basic steps: 

1. Define the Problem 

2. Develop an Informal Strategy 

3. Formalize the Strategy 

"Defining the problem" involves the development of a concise 
paragraph in English that specifically outlines the real 
world problem. "Developing an Informal Strategy" is to 
develop an English paragraph than as clearly and concisely 
as possible describes how one will solve the problem. This 

second step is really the mosr difficult part of the method- 

ology, since the resultant success of the design resrs on 
how well this can be accomplished by the designer. The last 
portion "Formalize the Strategy" is where the algorithm 
begins to take shape. First, the designer must pick out the 
proper ncuns that describe the "objects" of the solution 
strategy. Those objects are discribed in terms cf major 
objects and attribute objects. Next, the Informal Strategy 
is again scrutinized, this time to pick out the verbs that 
represent the "operations" utilized in the solution stra- 
tegy. These operations are then grouped with the objects 
they logically affect in the informal strategy. Bcoch then 
would have the designer draw an object-oriented system graph 
depicting the objects as Ada "packages" and the operations 
as Ada procedures and functions within the packages. The 
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object-oriented system graph describes the hierarchial 
interfaces between the structures. Booch typically includes 
an Ada "subprogram*' as a controlling program that utilizes 
the developed packages. Finally, the package specifications 
are written in Ada utilizing the previously developed 
object-oriented system graph as a guideline for the inter- 
facing and specific procedure specification development. 
This was done in the design of a "Dynamic" model and Target 
Database system and is specifically shown in Appendix E for 
future use by the AEGIS Modeling Group. 

D. THE DATABASE 

Using the Ada design as a basis, the Target Database was 
designed for implementation in the PL/I and ASM-86 

languages . 

• In t erf acin q and Sto rage 

The AEGIS Modeling Group experimental computer 
depends cn a 32 k byte "common memory" board on the MULTIBUS 
to pass messages. The common memory board is further 
utilized for the commands to the RSMEX Data Warehouse 20 
mega-byte storage system and the buffered data items to be 
written cn and retrieved from the REMEX. A mapping of how 
the ccmmcn memory is currently partitioned is shown in 
Figure 2.1 The segmented memory base for the common memory 
is OEOOO hex and offsets are as shown. The REMEX Data 
Warehouse is also connected to the MULTIBUS and data is 
transfered to and from it in response to the formated 
messages. The processes for the operations of the REMEX are 
discussed in detail in the thesis work done by Almguist and 
Stevens [Ref. 6] and in the appropriate manuals [Ref. 7]. 
The basic message fcrmat utilized for this thesis is the 
read/write format [Ref. 8] (as specified in Figure 2.2). 
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0E0C0:0000 + + 

CP/M-86 



HCORTEX 



:4C00 + + 



: 5000 + + 

1 MICROPOLIS CMD.MSG. | 

I 

+ 

I MICROPOLIS BUFFER 



; 51 00 +- 

I 



; 5 300 + 

: 5400 i + 

I REMEX COMMAND MSG. | 

: 5500 + + 
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I REMEX DATA BUFFER | 

; 6020 i + 

< TABL 58 I 
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I TABL 8 I 
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MCORTEX DATA | 
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+ 



Figure 2.1 Common Memory Map. 

2 • Design Dec! s icns 

The Ada design for the Target-Database resulted in a 
system rhat protects and hides the actual database and how 
it was implemented from the user. In an effort zo incorpo- 
rate that design feature in the PL/I-36 implementation, the 
concept of using a specific module to perform all target 
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Fignre 2.2 EEMEX Read/Write Message Format. 

data conversion zo an appropriate output message formar, and 
then to perform the operations to place that formated 
message in -^he REMEX was conceived. This module is named 
Bld_datatase . Not only does it perform those tasks just 

mentioned, but because of it's modularity, it provides for 
future changes should the method of storing the database be 
modified, or the hardware device utilized for storage be 
replaced. In addition, the decision was made to stcre only 
the messages to be utilized for output, on the REHEX, rather 
than storing both the initial target data that produced the 
messages and the messages themselves. The reason for this 
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of REMEX data 



decision is to provide the fewest number 
seeking operations during the run of a simulation. By 
utilization of a data structure on the current iSBC 86/12A 
in RAM (Random Access Memory) to pre-build the proper 
sequence cf messages, only a write command will be required 
to retrieve data frcm the REMEX. Although this method 
requires more execution time during the creation of the 
Target- Data base , very little execution time is consumed 
during the emulation. The method utilized for creation and 
modification requires the partial re-building of the data- 
base for each change made to the Target-List of data. 

3 . Design 

The resultant design, modularized for implementation 
in PL/I procedures, consists of the following (see Figure 
2.3) : 

a. Control: This module contains the main menu where 

the user will be able to choose how he will utilize the 
Signal Processor Model. 

b. Create: This module allows the user to interac- 

tively construct the initial environment of targets and 
how they will change throughout the time of the simula- 
tion. 

c. Delete: This module allows the user to delete 

targets from the environment at any desired simulation 
time point. 

d. Change: This module allows the user to change the 

environment during the initial creation of the environ- 
ment . 

e. Euild_Datafcase : This module is not called by the 

control module, but interfaces between the database 
utilized to represent the environment and those modules 
utilized through "control" to initially create and 
further modify and run the simulation. It must be able 
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to huild a set of output messages based on the 
previously developed target data, and to send these 
messages to the REMEX for storage. 
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Figure 2.3 Database Design. 
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E. THE STATIC MODEL 



Ih€ design of the Static model depends on the ability to 
read sequentially arranged previously stored output messages 
from the hard disk. When keyed by a dwell command from the 
SPY-1 A Track Scheduling module, an output message will be 
placed in common memory providing the SPY-1 A Sadar 
Controller system with feedback. It does not matter whether 
the output message offers a "logical" response to the 
requested dwell, just that it offers a response that will 
cause the SPY-1 A System to send another dwell command. 3y 
timing the SPY-1A System as it runs in interface with the 
Static Model, the user will be able to acertain the real- 
time performance of the SPY-1A model and whether cr not the 
concurrent multi proccessor system can indeed operate within 
the specifications of the AEGIS SPY-1A Radar Contrcller 
system. 

Utilizing the previously discussed target database 
design, a Target Database to be utilized by the Static Model 
can be created. The Static Model consists of functional 
modules that must be able to retrieve sequential data from 
the REMEX Data Warehouse, and respond to each new dwell 
command (tabl_58) sent by the Radar Scheduler with a set of 
one cr mere feedback messages (tabl_8) that would have 
resulted from a simulated radar dwell. To enable the capa- 
bility tc time the turnaround speed of the SPY-1A Model, a 
CRT display will be required that allows measurements to be 
made. It is important that the display include only the 
minimum data so that it will not impede the performance of 
the Static Model, and thereby detract from the objective of 
measuring the SPY-1 A System Model real-time performance. 
Figure 2.4 shows the Static Model functional modules in a 
hierarchial design. It is envisioned that the concurrent 
activity of the SPY-IA Radar Controller and the Signal 



26 



+ ---- + 
I • 

• CCNTBOL * 

I • 

+ ---- + 



+ + 

I I 

I STATIC I 

I I 

+ + 

I 

I 

+ + + + 



+ ► + + 



+ 



AWAIT 


1 

1 LOAD 


1 

1 DISPLAY 




1 BUFF 


1 


+ ^ 


^ 1 


+ + 



+ + 



+ + — + 



+ + + 

I I 



+ 



•- + + 

I II I 

I EIC MSG I I SEND MSG | 

I ■ I I "■ I 

♦ + + ,4 



+ + + 4 + 



I XFER MSG| I ADVANCE 
I ■ I I EVC. 

+ + + + 



Figure 2.4 Static Model Design. 

Processor Simulation will be sequenced using the MCORTEX 
Operating System functions [Ref. 9] implementing Eventcounts 
and Sequencers. Thus, although that interface is net avai- 
lable now, the AWAIT and ADVANCE primitives will be used at 
some future date by the AEGIS Modeling Group. In the mean- 
time, in keeping with the design goal of changeability 
(separating and modularizing those irems likely to be 
changed), the AWAIT and ADVANCE primitives must still be 
incorporated in the design and implemented for proper sysrem 
testing . 
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III. IBPLEMENTATICN of the SIGNAt PR OCE SSOR SIMOLATION 
A. TARGET HARDHARE 

The present experimental computer system consists of a 
MULTIEOS backplane that contains enough space for twelve 
(12) Intel SBC 86/1 2’s (Single Board Computers) , four (4) 
ADM-3 terminals connected to the four (4) currently 
installed iSBC 86/1 2A boards and two different hard disk 
memory storage devices. (see Figure 3.1). The main storage 
device is the Remex Cata Warehouse disk unit [Ref. 8] which 
contains two standard 8 inch IBM format floppy disk drives 
(one cf which is used to boot the system) , and a four head 
fourteen inch Winchester technology hard disk containing 
twenty mega-bytes of store. The orher storage device is the 
Micropolis Hard Disk system [Ref. 10] which has five heads 
and contains an additional thirtyfive mega-bytes of storage 
space. In both storage systems, the user, under the CF/M 
operating system, is allowed to write only to the disk that 
the terminal device was initially logged into, although full 
read capability across all fixed srorage devices is allowed. 
Shared memory consists of 32K bytes of Random Access Memory 
(RAM) that has been assigned the base address of OEOOOtOOOO 
hexadecimal. Occupying one of the twelve board slots, there 
is also a non- vclat ive bubble memory which was in the past 
utilized for the boot precedure during initialization 
[Ref. 6] but is currently utilized as temporary storage to 
boot the operating sjstem into each of the iSBC 86/12 boards 
in use. 

The Intel SBC-86/12's use an 8 Mhz clock and contain 64k 
of internal memory that can be used for on board processing. 
Each cf the iSBC 86/12' s is connected to an ADH-3 terminal 
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that is used for communication. The operating system is 
Digital Research’s CE/M~86 [Ref. 11] as modified by previous 
thesis students [Ref. 6] to enable the sharing of peripheral 
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Figure 3.1 NPS AEGIS Modeling Group Experimental Computer. 

devices. There is an executive called the "Multicomputer 
Real Time Executive" (MCORTEX) [Ref. 9] that has been 
written tc allow fcr concurrent computation by the SEC's. 
It occupies close to 6k bytes of storage on each of the 
SBC's. It is projected that it will take aproximately 8 or 
9 SBC's to carry out the same processes that the four AN/UYK 
7's presently do in the Spy-IA Radar Controller. 
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B. SCFTSIBI DEVELOPHENT ENVIRONMENT 



Recent aquisitions by the NPS AEGIS Modeling Group have 
made the Software Development Environment available on the 
experimental computer much better. The multicomputer system 
operates under the CE/H-86 operating system. In the past, 
programing has been done with Intel's PLM-86 Compiler and 
the ASM-86 Assembler for use on the iSBC 86/12. The SPY-1A 
major modules have been written utilizing the PL/I-80 
Compiler based on the Intel 8080 microcomputer. Now, the 
FL/I-86 Compiler [Ref. 12] has been released and is avai- 
lable for programming use. Because of the requirement for 
128 k-bytes of RAM for the use of the PL/I-86 Compiler, it 
can only be utilized by one of the four users at a time. In 
addition, where in the past programmers have gone to great 
lengths to avoid the use of the only available CP/H-86 text 
editor ED, the full screen text editor WORDSTAR is now 
available . 

C. ADA DESIGN VS PL/I-86 IMPLEMENTATION 

The previously discussed design process utilizing Ada 
was insightful and useful as a tool for program development, 
but the implementation language for the AEGIS Modeling group 
is PL/I. The primary struoture resulting from the object- 
oriented design methodology is the Ada "package”. The 
package in Ada serves to promote data abstraction and infor- 
mation hiding. PL/I does not offer a construct similar to 
Ada's "package" structure, but abstraction of the data mani- 
pulation and hiding the form of the implemented database can 
readily be achieved. The modules that are contained within 
rhe Ada packages are written as a logical grouping of proce- 
dures - the primary module structure in PL/I. The subpro- 
gram utilized as a control program in the Ada design is 
logically implemented with a controlling procedure, the 
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"procedure options (main) " in PL/I. The Ada package 
containing the target information is implemented with the 
global declaration "CEASE. DCL" and the resulting linked list 
used to develop the Target- List. The Ada database package 
is implemented with the PL/I array data-s tructure "BUFFER", 
which is hidden within the "BLD_DATABASE" procedure. The 
"BLD_,CATAEASE" procedure is not accessible directly to the 
user, and thus further hides the form of the database. 

D. BODOIES CF THE TARGET DATABASE 
• G enera l Com ments 

A useful feature in PL/I is the "%INCLUDE" statement 
which allows one to make the compiler include programs or 
declarations that have been previously written. This 
feature is most commonly utilized to include declarations 
that are used by more than procedure throughout a system. 
The "glcbal declarations " (DBASE. DCL) utilized in the 
Target-Database modules are treated in this manner. Fuxure 
maintenance on the Signal Processor Interface Simulation 
that may modify the Target-List, can be made to DBASE. DCL, 
and after the program is re-compiled and re-linked, it will 
appropriately affect all the perrinate modules. In addi- 
tion, two glcbal variables within the functional grouping of 
■he Target-Database modules are defined. These variables 
are declared as "external" initially in the main procedure 
"Control", and are also part of the global declarations 
utilized by the Target-Database. The two variables are 
"delta_t" and "endtime", and should be noted and protected 
appropriately by any future changes made to the modules of 
the Signal Processor Interface Simulation. It should be 
noted that "delta_t" is not utilized by either the 
Target-Database or the Static Model, but has been included 
because it will impact on the future use of the Signal 



Processor Interface Simulation, It is meant to define the 
ratio of how many dwell commands are received versus the 
number cf times the database buffer in common memory is 
updated. "Delta^t'* is meaningful for the Dynamic Model and 
will impact cn the length of time a test run will be able to 
run (based on available memory space for a database and 
chosen delta_t) . 

2 • CCN IHOL . PLI 

Ihe Control procedure is the head node of the 

hiararchial structure of procedures used to modularize and 
structure the i iiple nentati on of the Radar Signal Processor 
Interface Simulation. It contains the Main Menu that the 
user will be continually coming back to to route himself to 
other functional branches of the tree-like system. The Pl/I 
exception handler ON <condition> <body> is utilized first 
here and throughout the other modules to prevent abrupt 

program termination and promote graceful recovery in the 
event of user entry errors. Within the ON-body a series of 
IF-THEN statements are used. These will allow one to deter- 
mine in which interactive block the error was commitned. 
The variable named ’'block** is set to different integer 
values nhrcughout the program to signal where the user is, 
and where is the appropriate place in the program to renurn 
the ccntrcl, so that interaction can continue. The reader 
may be aghast at the flagrant and apparently unstructured 

use cf **gc to**s in this and further modules within the 

On-bcdy exception handlers. One should be assured that 

exception handlers are probably the only generally accep- 
table and appropriate time to use the **go to** in a struc- 
tured program. PL/I a dddit ionally offers a further 

exception handling feature, the SIGNAL <condition> command. 
When used in conjuction with an IF <condition> THEN 
<statemsnt> control command, the signal command has the 
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effect of "signalling" the system that the defined error 
(the condition of the signal call) has occured. The control 
is transfered automatically to the appropriate ON-unit 
defined for that signalled error. This enables the 
programmer not only to gracefully react to defined sysrem 
errors, tut to define his own error conditions and gracefuly 
continue operations. The Control module and the ether 
modules in the Signal Processor Emulation utilize this 
feature tc prevent the user from entering a response outside 
the defined allowable range. Finally, the REVERT <error 
type> statement is required at the end of each module where 
the ON exception handler is utilized. A stack is utilized 
in PL/I to save the state of the currant ON-conditiens when 
calling ancther procedure. PL/I-86 allows sixteen nested 
ON-units on the stack. Proper utilization of the REVERT 
command will pop the stack appropriately to ensure that the 
proper CN-unit is used. Functionally, the Control procedure 
sets up the global variable "endtime" that is utilized by 
the other Target-Database modules (create, delete, change, 
printlsr, and bld_database) to define the limits of time for 
which the database is to be consrructed on the REMEX Data 
Warehouse. 

3. CREA^.PLI 

The Create procedure has the function of interac- 
tively contructing a linked-list (the Target-List) of target 
nodes that contains the data for the database of discretely 
timed output messages (tabl-8). The linked list utilizes a 
pointer tc the header node (appropriately called "head") 
that will be used by the other modules in their subsequent 
manipulations of the Target-List. The other two pointers 
utilized (tgt_ptr, and tg t_mkr) are used to traverse the 
linked list and manipulate fields on nodes, or nodes them- 
selves. The PL/I '"?INCL0DE" sratament allows the 
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dsclaraticn of the linked list structure “Target" withcur 
having tc declare it in every module it is referenced. The 
Target-List is implemented as a linked list to allow the 
most efficient use of storage during the run-time environ- 
ment of the system. FL/I will only initiate storage for the 
nodes of the linked list during run-time, as required by the 
“ALLOCATE" command. Thus, instead of being restricted to a 
particular array size (had that data strucrure been used) as 
allocated at compile time, the user is restricted to the 
available memory at that time. In this version, the 
Target-List is constrained tc 56 nodes (or targets) , since 
the buffer size and corresponding sector size of the P.2MEX 
Data Warehouse is fixed at 5'12 bytes. After the user stops 
building the Target-List, the initial Target-Database is 
constructed with a call to the "Bld_darabase" procedure. 
Note that the first parameter to Bld_database is a constant 
"1". This will ensure that the first database built on the 
EEMEX begins at the first discrete delta_t time value. 

4. DELE^.PLI 

The purpose of this module is zo delete target nodes 
from the Target-List as requested by the user. The user has 
previously interactively indicated the specific discrete 
"time_in" value of the call, and this information will be 
further utilized by the procedure "Bld_database“ in its call 
by Delete. Delete will request a target node number of the 
node to be deleted ficm the Target-List. Then, the pointers 

snd rgt_mkr are utilized to traverse the linked list 
until the appropriate target node has been located. When 
found, the target node is separated from the Target-List, 
and placed back in available free memory store by the use of 
the PL/I "FREE" command. If the target node can net be 
found (indicated by the pointer tgt_ptr reaching the "null" 
node) , the user will receive an error statement and the 
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While Iccf controlling this process will return the user t 
ash if there is another node to be deleted. When the user 

has deleted all the targets he desires# the call will be 
made to the '• Bl d_dat abase" procedure to re-build the data- 
base from the previously defined del~a_t discrete time 
increment ("time_in") to the previously defined "endtime". 
Control will then return to the Main Menu (the Control 
procedure) . 

5. CHANGE. PLI 



The Change procedure is similar to the Create proce- 
dure since it allows the user to re-define the fields of any 
given node on the linked list Target-List in an interactive 
mode. Once again, in a manner similar to the Delete proce- 
dure, the user will define the discrete delta__t time value 
where the Target-List is to be changed, prior to the call to 
Change. This value "time_in" will be passed to the 
"Bld_dat abase" procedure in the same manner as with Delete 
for further Target-Database re-construction. The Change 
procedure allows the user to not only change the parameters 
used by the defined parametric equation but to change the 
equation (and therefor the shape of the resultant track) 
irself. The user is placed in a While loop to change all 
the targets he desires on the Target -List, until he indi- 
cates he is finished. At that time the procedure 
"Bld_ database" is called to re-build the Target-Database on 
the BEMBX Data Warehouse from the time given in the first 
parameter "time__in" tc the "endtime", both previously deter- 
mined by the user. 

6. BLD DATABASE. PLI 



This module is the real workhorse of the 
Target-Database building system. The purpose of the 
Bid database module is to convert the data contained on the 
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Target-List to an Array of output messages to be placed in a 
based structure called "Buffer", and then to transfer that 
Buffer tc another buffer of equal size in the NFS experi- 
mental computer’s common memory. At that time, the appro- 
priate message will be sent to the REMEX Data Warehouse 
commanding it to read the data (using Direct Memory Access - 
DMA) onto the required track and sector of the REMEX hard 
disk. To accomplish these tasks, Bld_darabase utilizes 
three assembly language routines: Bld_buff, Euild_cmd_mess , 

and Send_mess. Bld_huff utilizes the pointer to the struc- 
ture "Buffer" and causes the structure to be copied into 
common memory starting at location 0E000:5500. 
Buil d_cmd_mess uses 8 parameters to build an appropriate 
REMEX command message formated for a "read" operation into 
common memory starting at location 0E000:5400. Send_mess 
tells the REMEX it has a command message at location 
0E000:5400 and verifies that the REMEX has received and 
responded to the message. Bld_database utilizes these three 
primitive routines within two sub- procedures 

"bld_msg_tuf fer " and "call^rdw". The subprocedur es them- 
selves are called sequentially from within the execution of 
a PL/I DC loop that runs from the Bld_database parameter 
"time_in" to the global variable "endtime". The astute 
reader may now see why the user needs to build his 
Target-Database in a sequential manner, making deletions and 
changes in a progressively increasing discrete time incre- 
ment up to "endtime". If modifications are not done in 
discrete sequential time, Bld_database will write over the 
changes that had been already written to the database with a 
higher value time increment than the current "time_in" 
defined. The sub_procedur e bld_msg_buf f er will utilize the 
Target-List to build a corresponding output (tabl_8) message 
to be incrementally placed in the Buffer structure sequen- 
tially as the linked list is traversed. Reaching the "null" 
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and a call tc the 



node will cause the while loop to end, 
fcld_buff priiritive routine to be made. The x, y, and z 
named fields for each component of the Buffer array will be 
constructed by the parametric equation number indicated in 
the Target-list, These parametric equations were derived 
from a previous thesis work done by Boone [Ref. 3] and are 
utilized here tc maintain overall SPY-IA system compati- 
bility and integrity. See Figure 3,2 for a listing of the 
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Figure 3.2 Signal Processor Track Parametric Equations. 

parametric equations. These parametric equations can easily 
be changed if desired by future users of this sysrem, if 
specific requirements so dictate it. The sub- proced ure 
load_rdw uses the primitives build_cmd_mess and snd_mess to 
cause the EEMEX to read the data from the common memory 
buffer. Two of the parameters to the routine Build_cmd_mess 
require the track and sector to be designated where the 
REMEX will subsequently store the common memory buffer. To 
ensure that the track and sector are located in a sequential 
and therefore easily retrievable manner, a set of simple 
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algorithiis were devised. The algorithms will require buffers 
to be stored starting at a location indicated by ''time_in" 
and sequentially building each of 39 sectors per hard disk 
track until •'endtime" is reached or the memory is depleted 
(at track 210). The algorithms are: 

sect = 1 + mod ( time_in,U0) 
track = 1 + tru nc (t ime__in/39) 

The "sect" algorithm will convert time_in to a modulo 40 
number (0-39) and add 1 (since the sectors are number 1 to 
39 per track). The "track" algorithm will divide time_in by 
39 and truncate the resultant number to get an integer. It 
then adds 1 (since tte REMEX does not allow the use of track 
0 to the user) . The subsequent calls are then made to 
buil d_cmd_mess and snd^mess in that order. Upon completion, 
Bld^datatas? returns to the procedure from where it was 
called (Create, Delete, and Change) and then to Ccntrcl to 
the Main Menu once again. 

7. PR iitlst.pl I 

The Print^lst procedure is meant to be a tocl for 
the user tc maintain a listing of the Target_List as the 
list is initially created and as changes are made during a 
database building session. The procedure will prompt the 
user to turn on the printer or hit <control> "?•' to activate 
the printer, before typing "0" to begin a print of the 
Target^List . The Target-List print out will be initialized 
with a record of the time in ("time_in") for proper record 
keeping, and the linked list will be traversed, reading and 
printing the fields contained on each node. When the "null" 
node is reached, the procedure returns control to the 
Conrrcl procedure Main Menu. 
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E. BODOLES OP THE STATIC MODEL 
• Gen era l Com ments 

The purpose of Static Model is to run through the developed 
Target-Database in as rapid a manner as possible, reponding 
to eventccunts from the SPY-1A Model (indicating a dwell 
command has been sent) by transfering a output message to 
common memory. The SPY-1A is then further notified that a 
massage is ready for it's input by the advancing of a 
corresponding eventccunt. The display of the Static Model 
is merely a counter indicating each data transfer made (set 
of output messages) from the REMEX Target- Database to common 
memory, and the anticipated endtime (or endpoint) for the 
Static Model simulation run. 

2. STATIC.? II 

The Static procedure is the main procedure for the 
running of the Static Model. The procedure can operate in 
cne of twc possible mcdes. The first mode is an actual run 

of the NPS SPY-1A Model as it will be eventually interfaced 
for testing. It is assumed that the MCORTEX operating 
system will be utilized to enable proper interaction between 
concurrent processes, therefor eventcounts and sequencer 
primitives are used in the calls herein (which will be 
replaced by appropriate calls to that operating system at 
some future time). In the meantime, to allow testing of the 
Static Model, an AWAIT primitive was written, and an ADVANCE 
primitive is utilized in the test program SPYTEST. The 
Static Model will loop through the Target database in a PL/I 
DO loop from discrete time 1 to endtime. Within the loop, 
sequential calls are made to AWAIT, Load_buffer, 
Send_cutput, and Display. When the user begines a test-run 
with the SPY-1 A Simulator, he will be prompted to load that 
program cn another iSBC 86/12 console, and then begin 
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operating. At that point, the same loop will be run as 
previously described. The user may also leave the Static 
Modal and return to Control's Main Menu. 



3. I C AC_B U FF. PL I 



The purpose of this module is to extract the proper 
sectcr/track combination cf data from the REMEX 
Target-Database, and place it in the common memory buffer. 
It is the same as the Bld_Buffer sub-procedure previously 
described as a part cf Bld_database , except the parameters 
to the primitive routine Build_cmd_mess are to "write” 
instead cf read. 



4. X5ER.A86 

The purpose cf this module is to transfer a output 
message (tabl_8) from the common memory buffer to common 
memory location starting at 0E000:6055. 

5. ADV1 EVC . A86 

The purpose cf this module is to advance an event- 
count in common memory to notify SPYTEST.PLI that the output 
message is ready to be read. 

6. DISPLAY. PLI 

The purpose cf this procedure is to send to the 
terminal screen the "time” corresponding to the seguential 
transfer cf sectors of data from the REMEX Data Warehouse, 
and show the user the expected endtime for that particular 
run. This should enable the user to determine the "real- 
time” capability of the SPY-1A Model. 
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F. 



aSSEMBLY, COMPILING, AND LINKING 



The assembly language cole was wrirzen in ASM-86 and 
assembled using HASM-86. This assembler produces reloca- 
table files that can then be linked with compiled PL/I -86 
files. The PL/I-86 Ccmpiler was utilized for compilation of 
the Pl/I programs, and the resulting assembler and compiler 
".OBJ” files were then linked using LINK86 . The LINK86 
linker enables the user to develop a ".INP" file conzaining 
the list cf program commands the user would normally have to 
type in, and the linker can then be optionally utilized with 
the command '•LINK86 <file name>.INP [INPUT]”. This greatly 
speeds the link process and assists during run-time testing 
and debugging. See [Ref. 12] for furzher information. 

G. TESTING 

Mcsz cf the imp lemenza tion of the PL/I code was done 
using PL/I-80 instead of PL/I-86. This was convenient 
because of the extensive availabilizy of microcomputers 
using PL/I-80 versus PL/I-86. Most of the early testing was 
done via extensive code reading and revision. As a result, 
during top-down testing of modules, (utilizing program stubs 
for the assembly language subroutines) , the system worked 
with few runtime errors. Initially, the linked system did 
not contain the PHINTIST.PLI code it now incorporates. This 
code was developed as a test routine to insure that the 
Target-List and the Buffer data structures were being built 
in the proper manner and receiving the proper data. However 
the program was perceived as a desirable tool for recording 
target data while developing a Target-Database in the Signal 
Processor Interface Simulation, and was therefore incorpo- 
rated into the system. The top-down testing philosophy 
enabled testing to be implemented in PL/I-80. This provided 
programming and testing flexibility when the experimental 



4 1 



computer became a contended resource 
The use of DDT-86 (Dynamic Debugging 
locations and incrementally run the 
most important tool for testing and 
Processor Interface Simulation when 
routines were linked and the expe 
utilized . 



by AEGIS group members. 

Tool) to check memory 
system proved tc be the 
verifying the Signal 
the assembly language 
rimental compurer was 
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IV, C OHCLOSIO HS 



A. OITLIZATION AND CHANGABILITY OF THE SIGNAL PBOCESSOR 

SIHOIATION 

The Signal Processor Interface Simularion is a tcol that 
can be cf significant value to future testing of the NPS 
AEGIS Group's AN/SPY-1A Radar Controller Model. The 
Target-Database system was developed to allow it's use not 
only with the Static Model as specifically implemented in 
this version, but also as the basis for a version to inter- 
face with a Dynamic Model. The individual functions that 
make up the total Signal Processor Simulation Sytsm have 
been modularized to enhance the use and adaptability of this 
version to what ever future directions the Simulation 
efforts cf the AEGIS Modeling Group may be. A comprehensive 
Users Manual has been provided in Appendix F for use with 
this version of the Signal Processor Simulation as a stand 
alone document. The only interfacing required for the 
members cf the AEGIS Modeling Group with regards to this 
Signal Processor Simulation should be the substitution of 
MCORTEX "await" and "advance" primitives for those utilized 
in this version of the Static Model, and the possible 

restructuring of the address locations in common memory. It 
is recommended that any tester of the NPS SPY-1A Radar 
Controller Model first gain experience of the Signal 

Processor Simulation by running the Simulated SPY-IA Program 



"SPYTEST. CMC". 



B. FDTDBE ENHANCEMEUTS AND DIRECTION FOR THE SPT-1A MODEL 



The next logical step in the full implementation of the 
Signal Processor Interface Simulation is the further design 
and implementation of the Dynamic Model. The purpose of the 
Dynamic Model is to test the logic of the NPS SPY-1A Radar 
Controller Model. The Dynamic Model does not require the 
real-time performance of the Static Model, but must provide 
a comprehensive display of the active targets representing 
the Target- Database at each discrete rime increment. The 
Target-Database system developed in this thesis should 
provide the basis for changing the structure of the 
Target-Database as the limits of the logical functions of 
the system are explored. However, the Target-Database has 
been purposefully designed for change should that be neces- 
sary in the implementation of the Dynamic Model. Previous 
thesis work by Boone [Ref. 3] should assist in the develop- 
ment of the Display module required for the Dynamic Model. 
Finally, the messages utilized (tables 58 and 8) for input 
and output from the Signal Processor Interface Simulation 
will require some attention. Specifically, the output 
message (table 8) needs to have some data from the input 
message to allow the SPY-1A Radar Controller Model to prop- 
erly recognize and match input dwell commands with output 
data . 
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APPE NDIX A 

TARGET DATABASE PROGRAH LISTINGS 



A. CCNTEOL.PLI 



Frog Name : CONTROL. FLI 

Date : May 83 

Written by : Toad B. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodres 

Furpose : This is the main program to conrrol the 
operation of the Signal Processor Simulation Target 
Database functions and the Static Model funcrions. 

*/ 



control ; procedure options (main) 



declare 

cr sat e ent r/ ( 
delete entry/ 



0 inter) , 

, ixed ,Doxnter) , 

change entry ( fixed, po inter) , 
printlst entry (pointe r, fixed) , 
static entry ; 



declare 

block fixed binary (7) , 

init fixed decimal (2 , 1) , 

initi fixed, 

choice fixed binary(7), 

delta t fixed decimal (2,1) EXTERNAL, 

endtime fixed decimal (4, 1) EXTERNAL, 

time in fixed, 

hsad~point er ; 

entry errors */ 

on error (1) 
b e a i n ; 

'if block = 1 then do; 

cut list (ascii ( 26) , ascii (30) ) ; 

put skin list (' invalid entry, try again...'); 

go to start; 

end ; 

if block = 2 then do; 

cut list (ascii ( 26) , ascii (30) ) ; 
put skip list (' invalid entry, 

must be integer 1-6...*) 

go to menu; 
end ; 

if block = 3 then do; 

put li St (ascii ( 26) , ascii (30 )) ; 
put skip list (' invalid entry, 

must be 1- ' ,endtime, ' . . . ') 

go to branch; 
end ; 

end ; 



cut 

put 

put 



list (ascii(26) . 
skip list (^ * 

skip list (' 



ascii (30)) ; /*clear screen */ 

SIGNAL PROCESSOR SIMULATION 

version 1.0 June 1983') ; 



) 



45 



put skip (2) ; 
start: 

/♦ First determine what the time interval for display 
updates and corresponding updates from the database will 
be, as well as the length or the simulation */ 

iDXcck “ 1* 

put skip list ('SYSTEM INITIATION; (see users manual)*); 
put skip list ('How often do you want the database and 

the display updated?*) ; 

put skip list (' (delta t range . 1 to i seconds) *) ; 

put skip list?' (default is every ,5 sec)'): 

put skip list ('enter value or 0 for default: •); 

get list (init) ; 

if ( (init>1 ) I (init<. 1) ) then signal error ( 1) ; 
else delta t = init; 

put skip list ('How many seconds do you want the 

simulation to run?*); 

put skip list (' (endtime range 1 

to (delta t * 8 190) ) ' ) ; 
put skin list (' (default is 300 sec)*)T 

put skip list ('enter value or 0 for default; *) ; 

get list (init i) ; 

if ( (init 1>8 1 90) | (initKI)) then signal error (1) ; 
else endtime = initl; 

/* Next the user will be placed in a interactive 
environment where he can build track databases, 
run simulation tests, and change the track database 
as ke desires */ 



do while ('1 * b) ; 

put list (a scii (26) , ascii (30)) ;/* clear screen ♦/ 
menu : 

* 2 * 

put skip iistc MAIN MENU ****); 

put skip (2); 

put skip list ('What course of action do you wish?*) ; 

CREATE a database of tracks'); 
(you must do this first)*); 



DELETE a track from the database*); 



CHANGE 

FEINT 



dat abase 
(5) RON 



a track on the database*); 
the current target list*); 



is satisfactory 
a si muiation *) ; 



you may: *) 



put skip lis 
put skip list 
put skip list 

C ( 2 ) 

put skip list 

“ (' ( 3 ) 

put skip list 

put Sk:;.p(1); 
put skip list 

( ' Af t er a 
put skip list ( ' 
put skip list 

(insure the rest of the SPY-1 Model is setup)'); 
out skip list 

* (» (b) QUIT and return to the operating system'); 

put skip list ( * (enter 1-6 and <cr>) : *) ; 
get list (choice) ; 

if ((choice<1) |(choice>6)) then signal error(l); 

branch: 
b ic clc — 3 * 

if choice’ = 1 then call create (head) ; 
if choice = 2 then do; 
put skip list 

('At what time do you wane to delete a target? '); 
get list(time in) ; 

if ((time in<n)|(time in>endtime) ) 
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then signal errcr(l) ; 

call delete (time_in,head) ; 
end ; 

if chcice = 3 then do; 
put skin list 

('At what time do you want to change a taraet? '); 

get list(tinie in); 

af ((time in<l) | (time in>endtime) ) 

"* ~ then signal error (1); 

call change (time in, head); 
end ; “ 

if choice = 4 then call printlst (head, t ime in); 
if chcice = 5 then call static; ” 

if chcice = 6 then do; 
put skip(2) list 

(• *** END OF SIMULATION *♦♦•); 

revert error Cf) ; 
step; 

0n Q * 

end; while */ 
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E. 



CBEAIE. FU 



end central; 

Prog Name : CREATE. ELI 

Care : May 83 

Britten by : Todd B. Kersh 

For ; Thesis (AEGIS Modeling Grouo) 

Adviser : Professor Kodres 

Purpose ; This module is part of the Target 

Database package of functions. 

V 

create: procedure (head) ; 

/* Global declarations */ 

^include ’dbase.dcl'; 

/* Local declarations ♦/ 
declare 

bid database entry (fixed, pointer) , 
i fixed binary (7) , 

cent character(l) static init(’Y’), 
block fixed binary (7) , 

tgtnuii fixed binary(7) static init (0) external, 

xrange float, 

yrange float, 

xvel float, 

yvel float. 

xacel float, 

yacel float, 

alt float, 

tgteq fixed binary (7) ; 

entry errrors */ 

on error (1) 
begin ; 

put skip list(’FHTRY ERROR, THY AGAIN...'); 
if block = 1 then 
go to retry; 
if block = 2 then 
go to again; 

end; 

put skip list('=== CREATE TARGETS MODULE ==='); 

/* Initiate the target list */ 

allocate target set(tgt mkr) ; 
tgt ptr = tgt_itkr; 
hea^ = tgt mkr ; 

tgt_ptr->num = 0; /* this is the header node */ 

allocate target set(tgt mkr); 
tgt ptr->next ptr = tgt~mkr; 
tgt_ptr = tgt“akr; ~ 

/* Create the list of targers to be simulated */ 

do while ( cont = ’Y'); 
tgtnum = tgtnum + 1; 
tgt ptr->num = tgtnum; 
retry : 
block = 1 ; 

put skip list ( 'Ini tia te target #', tgt num) ; 

/* Assign the target parameters */ 



48 



(’ 



(' 



put skip list 

(' Parametric Equations? (1,2,3,or4); '); 
get list (t gteq) ; 

if ( (tgte q<l ) I (tgteq> 4) ) then signal error (1) ; 

put skip list(' X range (a)? (-256 , + 256) nm: ») ; 

get list ( xrange) ; " 

if ( (xrange<-2 5b) I (xrange>256) ) then signal error (1); 

put skip list(» Y range (u) ? (-256 , +256) am: ') ; 

get list (yrange) ; “ 

if ( (yrange<-2 56) I (yr ange>256) ) rhen signal error (1); 

put skip list ( ’ X velocity (b)? (-32, +32) m/sec: •); 

get list (xvel) : 

if ( (xvel<-32) I (xvel> 32) ) then signal error (1); 



put skip list ( ’ Y velocity (v) ? (-32, +32) m/sac: '); 

get list (yvel) ; “ 

if ( (y vel<-32) I (yvel> 32) ) rhen signal error (1); 



put skip list 

X_accelera tion (c) ? (-. 0 15625 , + . 0 156 25) m/sec/sec : *) 
get list (xacel) : 

if ( (xaceK- . 0 15625) 1 (xacel>. 0 1 5525) ) 

then signal error (1) 



put skip list 

Y_acceleration (w) ? (-. 0 15625, + . 015625) ra/sec/sec: *); 
get list (yacel) : 

1 f ( (yacel<- . 0 15625) ( (yacel> . 0 1 5625) ) 

then signal error (1); 



out skip list(' Z altitude (d)? (0,20,000) ft: *); 

get list (a It) ; ” 

if ( (alt<0) i (alt>2000 0) ) then signal error(l); 



tgt ptr->eg 
tgt ptr->a = 
tgt~orr->b = 
tgfptr->c = 
tgf'ptr->d = 
tgt“'p-r->u = 
tgt“ptr->v = 
- g t~ p t r- > w = 



: tgteq; 
xrange; 
xvel: 
xacel ; 
alt; 
yrange; 
yvel: 
yacel ; 



/* Determine if more targets are 



to be created */ 



am : 

i^^ock = 2: 

put skip(2) list('create more targets?(Y or N) : 
get list (cont) : 
if cont = 'y’ then cont = *Y*; 
if ((cent = ’ Y ’ ) 6 (tat num®=56) ) then do; 
allocate taroet set (tgt mxr) • 



tgt_pt r->ne XT ptr = tgt”mkr; 
tgt Ptr = tgt“mkr; 

endT 

if tgtnum = 56 then do; 

put skip list(»TARGET LIST IS POLL. 

cont = 'N’ ; 

end; 

end; /^while cont */ 
cent = ’Y*; 



•) 



/* Complete the linked list */ 
t gt_ptr->next_ptr = null; 



) ; 
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f* 



gt Dtr = head; 
gt~5ikr = head; 

/* Build the Remex Data Warehouse database. ♦/ 

put skip list (' BUILDING DATABASE '); 

call bid database (1, head) ; 
revert error ( 1) ; 

end create; 



50 



C. DELETE. PLI 



Prog Name : DELETE, PLI 

Date : May 83 

Written fcy : Toad B. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor ; Professor Kodres 

Purpose ; This module is parx of the Target 

Database package of functions. It delexes targets 
from the Target List, 

♦/ 

delete: procedure (time in, head); 

^replace ” 

urue by ' 1 'b, 
false by 'O’S; 

/* Global declarations ♦/ 

^Include 'dbase,dcl'; 

/* Local declarations */ 

declare 

bid database entry (fixed, poinxer) , 
found bit(1) static init (false) , 
time in fixed, 

tgtnum fixed binary (7) external, 

tgt fixed binary (7), 

cent character (1) static init('Y'); 

/* This exception handler will take care of 
all user input errors */ 

on error (1) 
begin ; 

pux skip list ('ENT BY ERROR, TRY AGAIN ,..’) ; 

go to retry; 
end : 

tgt = 0; 

put skip list('=== DELETE TARGETS MODULE ==='); 

/* This will initialize the Target linked list to the 
correct memory space */ 

tgt ptr = head->next ptr ; 
tgt^mkr = head; 

/♦ This will delete the desired node from the 
target linked list V 

do while ( cont = 'Y') ; 
retry : 

put skip list 

(' What target do you wish to delete? *)5 
pux skip list 

(' (tgt, num, range 1-' , tgtnum, ') : '); 

get list (tgt) ; 

if ( (tgt<1) 1 (tgt>tgtn um) ) then signal error (1); 

do while (found = false); 
if tgt ptr->num = tgt then do; 

tgt lkr->next_ptr = tgt ptr->next_ptr ; 

tgt”ptr->next ptr = null; 

free tgt ptr-'^targ et ; 

tgtptr = head->nexx otr; 

tgt mkr = head; 
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found = true; 
end ; 

6ls€ do; 

tgt_mKr = tgt ptr; 
tqt ptr = tgt“mkr->n<3xt ptr; 
it tgt ptr = null then Ho; 
put^skip list 

{'ERROR : target number not found'); 
tgt_ptr = head->next_ptr ; 
tgt_mkr = head; 
found = true ; 
end ; 

end; 

end; /* while V 
found = false; 

put skip list ( 'continue (Y/N)? ') ; 
get list (cent) ; 
if cont - 'y' then co nt = ' Y' ; 
and; /*while*/ 
cont = 'Y'; 



put sVip(2) list ( 'EOILDING NEW DATABASE...'); 
call tld_database (time in#head) ; 
revert error (1); ~ 

end delete; 
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D 



CHiHGI. ELI 



Frog Name : CHANGE. ELI 

Date : Hay 83 

Written by : Todd,B. Kersh 

For : Thesis (AEGIS Modeling Group) 

Adviser : Professor Kodres 

Purpose ; This module is part of the Target 

Database package of functions. It changes data 
on the Target List. 

*/ 



change: procedure (time^in, head) ; 

%r eplace 

€rue by ' 1 'b, 
false by 'O'd; 

/* Global Declarations */ 

?5include 'dbase.dcl'; 

/♦ Local Declarations ♦/ 



(f ixed, point er ) 



declare 

bid database entry 
time in fixed, 
more”bit,(1) static init(true), 
tgtnui fixed binary(7) external, 
tgt fixed binary(7[, 



(chg1,chg2) fixed binary (7), 
(ckg3,chg4 ,chg5 ,chg6 , cha7,chg8 , chg9) 
dol bitf1) static init (false), 
block fixed binary (7) . 
cont character (1) static inii('Y’); 



float , 



/* This exception handler will take care of all 
user input errors V 



on error (1) 
begin; 

nut skip list ('ENTRY ERROR, TRY AGAIN '); 

if block = 1 then 
go to tryl: 
if block = ^ then 
go to try2; 

end ; 



put skip list('= = = CHANGE TARGETS MODULE ===*); 

/* First, query the user about the changes to be made */ 



do while (cont = 'Y'); 
t’" V 1 • 

block = 1 : 
out skip list 

“■C What is the target number you wish to change?'); 
put skip list 

(' (tgt. num. range 1-' , tatnum, ') ; '); 

get list (tgt) : 

if ( (tgt<1) I (tgt>tgtn urn) ) then signal error (1); 



put skip list 
put skip list 
put skip list 
get skip list 
If ( (chg1<1) I 



' What data item is to be changed?' 

: — - 

chgl) : 

chg1>2) ) then signal error(l) 



parametric equation'); 
equation parameters'); 
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if chql = 1 then do; 
do 1 = true: 
put skip list 

What is the new equation number (1-4)?') 
get Iist(chg2) ; 

if ((chg2< 1 ) I (chg2 >4) ) then signal error(l); 
end ; 

else do; 
try2; 

block = 2; 
dol = false; 



(' 



put skip list (' What are the new parameters;') ; 
put skip list 

^ I- X_range (a)? (-256, + 256) nm; ') ; 

get list(chg3) ; 

if ((chg3<-256) I (c hg3>256) ) then signal error (1); 



put skip lisr 

... , ,(',., Y_range (u) ? (-256 , + 256) nm: ') ; 

get list (chg4) ; 

if ((chg4<- 256) I (chg4>256) ) then signal error (1); 
put skip list 

(’ X^velocity (b) ? (-32, + 32) m/sec: ') ; 

get list (ch g5) ; 

if ((chg5<-::2) I (chg5>32)) then signal error (1) ; 
put skit list 

(’ Y velocity (v) ? (-32, + 32) m/sec: ') ; 

get list(chg6) ;~ 

if ((cha6<-32) I (chg6>32)) then signal errcr(l) ; 



put skip list 

X accel. Jc) ? (-. 0 15625, + . 0 1 5625) m/sec/sec: 
get”list(chg7) : 

If ((chg7<-. 013625 ) 1 (chg7>. 0 156 24) ) 



') 



then signal error (1) 



, + . 01 5625) m/sec/sec; ') 
. 0 15625) ) 

then signal error (1) 

put skip listC Z_alt. (d) ? (0 ; 20 , 000) ft : ') 

get list (chg9) ; 

if ((chg9<0 ) I (chg9 >20000) ) then signal error (1); 
end ; 



put skip list 

Y accel. jw) ? ( 
get“list (chgfi) ♦ 

If ((chg8<-. 013625 



(-.015625 
) I (chg8> 



tgt ptr = head->next ptr; 
tgt“mkr = head ; ~ 

/* Now this will find the desired node, and make the 
requested changes on the target data list */ 



do 



while (more = true) ; 
if tgt ptr->num = tgt then 
if 3o1 = true then tgt_ 
else do; 

tgt ptr->a = chg3 ; 
tot”ptr->b = chg5; 
tgt~ptr->c = chg7 ; 
tgt ptr->u = chg4; 
tgt ptr->v = chg6 ; 
tgt~ptr->w = chg8; 
tgt”ptr->d = chg9 ; 
end ; ” 

more = false; 



do; 

pt r->eq 



chg2 ; 
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snd ; 

€lse do; 

tgt mkr = tgt_ptr; 
tgt“ptr = tgt_mkr->next ptr; 
if ^gt ptr = null then 3o ; 
put”skip list 

('EREOR : target number not found') 
tgt ptr = head->next ptr; 
tgfmkr = head; “ 

mere = false ; 
end; 
end: 

end; /* while */ 
mere = true; 

put skip (2) list 

('Do you wish to change another target?') 
put skip listC (Y/N): ') ; 
get list (con t) ; 
if cont = 'y' then cont = * Y' ; 

end; /♦ while */ 
cont = 'Y'; 

put skip (2) list ( 'UPDATING CHANGED DATABASE...'); 
call tla database (time in, head) ; 
revert error ( 1) ; ~ 

end change; 
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E 



BlDCEiSE.PLI 



Prog Name ; BLDDBASE.PLI 

Date : Bay 83 

Written by : Todd B. Kersh 

For ; Thesis (AEGIS Modeling Group) 

Adviser : Professor Kodres 

Purpose : This is the module the builds the 

database in the Remex Data Warehouse after the 
Target List has been created or modified. 

*/ 

bid database: procedure (time in, head); 
^replace ~ 

true by ' 1 *b. 
false by 'O'd; 

/* Global Declarations ♦/ 

%include 'dbase.dcl'; 

/* Local Declarations *'/ 
declare 

trmeend fixed, 

time in fixed binary(15), 

t fixed binary (15) , 

trkfull char(i) static init('N’)/ 

i fixed; 



/* This train procedure uses subprocedures to build 
the database cf table-8 structures in the Remex Data 
Warehouse */ 

t = time in; 

txmeend - trunc (endtime/del ta__t) ; 
do i = time in to timeend; 

call tld“msg buff er (h ead , t) ; 
call Icaa rdw (t) ; 
t = t + 1J 

if trkfull = 'Y' then return; 
end ; 

/* This procedure will create the Signal Processor 
Interface Simulation output message no the Track 
Processor Module for each node of the target list, 
and store them in a buffer. */ “ 

tld_msg_buf f er : procedure ( head, time_in) ; 

declare 



/* The Buffer contains all the track tables at time_in V 
1 Buffer static, 

/♦ Table 8; interfaces between the beam 
stabilization process and the track process */ 



2 B to P tabl(57) - 

3 x^sub s fixed binary (15) 
3 y_sub“s fixed binary(l5) 
3 z_sub"s fixed binary (15) 
3 face idx fixed binaryjf?) 
3 dwl idx fixed binary(7) 

3 trk^num fixed binary (7) 



init (0) , 
in it (0) 
init (0) 
init i 0) 
init (0) , 
init (0) ; 
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r 



declare 

bld^buff entry (1,2 pointer. 



56 



b it 
b it 






declare . 

tine_rn fixed binary (15) ; 
head pointer; 



declare 

more bit(1) static 
ctr fixed binary (7) 
equ fixed binary (7) 
(x,y, 2 ) flcat; 



in it (true) 

9 

9 
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declare 

1 carablk static, 

‘2 scurcebuff pointer, 

2 destbuff hit(16) init (' 5500' b4) , 

2 segaddr bit(i6) init ( ' eOOO ' b4) ; 

ctr = 1; 

/* First get the ncde of the target_data list and 
extract the data needed to generate the items 
on tbl 8 */ 



tgt ptr = head->next ptr; 
tgt“mkr = tgt_ptr; 

do while (more = true) ; 



buffer. b to p tabl (ctr ) . trk_num = tgt ptr->num; 
equ = tgt_ptr->eq; ” 

/* Derive values for target positions x,y,and z 
at time_in for the specified parametric equation */ 

i f equ = 1 then do : 

x=tgt_ptr->a + tgt ptr->b*time in 

~ tgt ptr=>c*time_in*time in 

y=tgt_ptr->u + tgt ptr->v*fame_in ” 

“ tgt_ptr->w*time_in*time_in 

z=tgt ptr->d; 
end ; “ 

if equ = 2 then do : 

x=tgt_ptr->a + tgt ptr->b*time_in 

“ “gt Dtr->c*time in*time in 

y=tgt ptr->u + tgt ptr-> v*sin (tgt ptr-15w*t ime_1n) 
z=tot“p tr->d; ~ ~ 

end; ' ” 

if equ = 3 then do; 

x=tgt ptr->a + tgt ptr->b*cos (tgt ptr->c*time in) 
v=tgt”ptr->u + tgt“ptr->v*time in” ” 

” “ tgn ptr“>w*time in*rime in 

z=tgt ptr->d; “ “ 

end ; ” 

if equ = 4 then do : 

x=tgt ptr->a + tgt ptr->b*cos (tgt ptr->c*time in) 
y=t^”ptr->u + tgt”ptr->v*sin (tgt”ptr->w*time”in) 
z=tgt”ptr->d ; 
end; ” 

buffer, b to p tabl (ctr) . x_sub s = x; 
buf fer . b”to”p”tabl (ctr) . y_sub”s = y; 
buffer. b”to“F“tabl (ctr) . z_sub s = z; 
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/* Set up tc look at the next target */ 

C't 3T ~ C^IT 1 * 

■^9't_ptr = tgt’mkr->next ptr ; 
tgt mkr = tgt”ptr; "* 

if fgt Ptr = null then more = false; 
end; /*dc while*/ 
more = tr ue ; 
tgt ptr = head; 
tgt“ikr = tgt_ptr; 

/* This will transfer the buffer structure to the 
ccmmcn memory board buffer location for transfer 
to the RZMEX. */ 

oarablk. scurcebuf f = addr(buffer) ; 
call bld_bu f f (b_ptr) ; 

end bld_isg_buf f er ; 

/* This procedure will cause the REMSX Data Ware- 
house to load the contents of the buffer into the 
next sector on the RDW hard disk. */ 

load_rdw; procedure (time_in ) ; 

declare 

time_in fixed, 
ssnd_mess entry, 

build cmd_mess entry (bit(16), fixed binary(15), 

" fixed binary (15), 

fixed binary (7), fixed binary(7), 
bit (16), bir(16), 

fixed binary (15)); 

declare 

status fixed binary(15) static init (0) , 
sect fixed binary (7), 

word count fixed binary(15) static init (256) , 
mem Bit(16) static init ('5500’ b4) , 
msb bit(16) static init { ' OOOe ' b4) , 
track fixed binary (15), 
head fixed binary(7), 

rdw read bit(16) static init (' 1 020 ’ b4) ; 

~ /* ”1020" means the REMEX will writs 

from the com. mem. buffer to the hard disk.*/ 

head = 0; /* this sets head to ”D” drive */ 

/* This determines the sector based on 39 sectcrs/track */ 

sect = 1 + mod (time_in, 4 0) ; 

/* This determines the track */ 

track = 1 + trunc (time^i n/39) ; 

/* need except, hndler for TRACK >210 */ 

if track > 210 then do: . ^ ,, 

put skip list('The database store is full.'); 
put skip list 

(' This run is recorded as ',time_in,' delta_ts.'); 
put skip list ~ ~ 

(' To create a longer run, change the value of delta t.'); 
trkfull = 'Y' ; 
return ; 
end ; 
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/* This procedure builds the command message required 
for the sEHEX Data Warehouse to read the data tables 
located in the buffer corresponding ~o the value 
of "time_in'*. */ 

call build cmd mess 

(r dw_read , szat us, track, head,sect, mem , msb, word_count) ; 

/* The procedure sends the command message to the pemex 
Data Warehouse to perform the required read operation V 

call send_mess; 

end lcad_rdw; 

end bld_dat abase ; 
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F 



PBINTISI.PLI 



Prog Name : PRINTLSI.PLI 
Data : May 83 

Written fcy : Toad B. Kersh 

For : Thesis (AEGIS Modeling Group) 

advisor : Professor Kodr es 

Purpose : This module is a diagnostic tool for 
the user to keep a record of the flow of the Target 
List as changes are made at each delta t, as a Target 
Database as constructed for a Static Model run. 

*/ 



printlsr; procedure (head, time); 
^include ’dbase.dcl'; 

declare 

prt fixed bin (7), 
time fixed, 

(head, ap, bp) pointer; 



put skip list(*=== PRINT TARGET LIST ===•) 
retry; 

put skip list (’To 
put skip list (’type 
out skin list (' 
get list (prt) ; 

if prt 0 then go to retry; 



get a print out, turn on printer, 
<ctrl> P, and then type 0<return>. 
Else, just type 0<return>. ’ ) ; 



put Skipl2) list ( ’TARGET LINKED LIST at time = ’ ,time) ; 
ac = head; 
bp = ap; 

ap = hp->next_ptr ; 
do while (ap ° = null ) ; 



bp 

out 

put 

put 

put 

put 

put 

put 

put 

put 

pu 



spp (2). ; 

skip list 



skip list ( ’ EQ 

skip list ( ’ a 

skip list ( ’ b 
skip 1 isx. ( ’ c 

skip list ( ’ u 

skip 1 ist ( ’ V 

skip list ( ’ w 

skip 1 ist ( ’ d 

ap = bp->next_ptr ; 
end; /* while */ 



TGT 



,aD->num 
’ ,ap->e 
’ , ap->a 
’ ,ap->b 
’ ,ap->c 
’ ,ap->u 
;,ap->v 
’ ,ap->w 
’ ,ap->d 






bp 



= head; 
= head; 



end printlst 
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G. DBASE. DCL 



Frog Name ; DBASE. DCL 
Date : May 83 

Written by : Toad B. Kersh 

For ; Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodr es 

Purpose : These are the global declarations 
for the Target Database. 



declare 

declare 



endt ime 
delta t 



fix ed 
fix ed 



decimal 

decimal 






external , 
external ; 



head pointer, 

(tgt_ikr ,tg t_ptr) pointer, 
1 target based, 

2 num tixed 



2 eg fixed 
2 para, 

3 a 
3 b 
3 c 
3 u 
3 V 
3 w 
3 d 
3 e 
3 f 

2 next_ptr 



binary (7) 
)inary (7) , 

float , 
float, 
float , 
float , 
float, 
float, 
float, 
float, 
float, 
po inter ; 
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B 



BLDB0FF.A86 



Prog Name : BLDBUFF.A86 

Data : 4 June 83 

Written by : Todd E. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodres 

Purpose : This routine will transfer a 256 word 

buffer from SBC private memory xo the com. 
memory buffer starting at E000:5100. The 
parameter passed is a parameter block containing 
a pointer to the buffer on SBC, and the base 
and offset to the oommon mem. buffer. 



Code Segment 



; This routine assumes parameters as follows: 
; paral oarameter block consisting of 
; 3 words. 

cseg 



bld_buf f : 
push ax 
Dush si 
push di 
push cx 
push es 



mov 


sir 


' bx 1 


mcv 


Sir 


’ si 1 


mov 


air 


" bx J 


les 


di,l 




mcv 


OX, ; 


256 


move words: 




mcv 


ax,| 




mov 


es ;| 


.ai 1r 



inc si 
inc si 
inc di 
inc di 

loop move_words 

pop es 

pop cx 

pop dj 

pop SI 

pc| ax 

end 



get location of buffi 
from para, passed 
assign location of buff 2 

; assign no. of words to move 

load word from source 
; store word into com. mem. buffs 
; adjust pointers. 



; loop if not dons 
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STATIC MODEL PBOGRAH LISTINGS 



A. STATIC. PLI 



Prog Name : STATIC. PLI 

Date ; 8 June 83 

Written by : Todd B. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodres 

Purpose ; This module controls the operation for 
the ECP Static Model. 

*/ 



static: procedure; 



declare 

load buffer entry (fix ed) , 
xfer“msg entry, 
advance avcl entry. 
disclay**entry (fixed) , 

Lit entry (fixed di 



awa: 



nary (15) ) 



declare 

start fixed binary (7) , 

thrshcld fixed binary (15) static init(1), 
endtime fixed external, 
item fixed binary(7), 

evcvalue fixed binary (15) sratic init (0) external, 
time fixed; 



/♦ This exception handler will take care of all 
user input errors. */ 



on error ( 1) 
begin ; 

pur skip list (• ENTRY ERROR, TRY AGAIN...'); 
gc to retry ; 
end ; 



put skip 
put skip 
put skip 
put skip 
put skip 

put skip 
put skip 
retry : 
put skip 



out 

put 

put 

get 

If 



skip 
skip 
skip 
lisx 
( (ite 



(asci 

list 

list 

list 

list 
( 2 ) ; 



i (26) , ascii (30)_) ; /* clr. screen */ 

(• === RSP STATIC MODEL ==='); 

(' version 1.0 June 83’); 

('At this pcint you should have created 
a database and are now ready to run'); 
('your test of the NPS SPY-1A Model.'); 



=== STATIC MODEL MENU ==='); 



list 
list 
list 
list 
(item) ; 

m<1 ) I (It em>2) ) then signal error (1); 



' (1) TEST run the simulation') ; 

'(2) QUIT and return to main menu'); 
'enter 1-2 and <cr>: '); 



if item = 1 then do; 

put skip list ( 'Load SPYTEST.CMD from another 

system CRI/SBC. ') ; 

put skip list ('When complete, enter 0<cr> 

to begin => ') ; 
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fo Oi 



get list (start) ; 
if stairj:« = 0 then signal error(l) 

do tine = 1 to endtime: 
call await (thresho Id) ; 
threshold = threshold + 1; 
call load buffer (t ime) ; 
call xfar“nisg; 
call advance evcl; 
call displayltime) ; 
end ; 

e return; 
revert error ( 1) ; 
end static; 
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B 



aHiIT.A86 



Prog Name 
Dar 6 

Writtan by 
For 

Advisor 
Purpose 
written to 
Scheduler. 



; AWAIT. A86 
; 8 June 83 
: Todd B. Kersh 

: Thesis (AEGIS Modeling Group) 

: Professor Kodres 

: This module checks to see if a msg has 
0E000:5614 of common memory by the fiadar 



been 



DATA 



CODE 



cseg 

public await 



await ; 
push 
push 
push 
push 
mov 



a X 
di 
si 
. es 

ax, Ce 00 Oh 
mov es,ax 
mov di,06020h 
mov si,[bx] 
lods ax 
poll 



cmp 

jnz 

pop 

pop 

pop 



end 



ax,es;[ di ] 
coll 
es 
si 
di 
ax 



; get common mem. base 
; assign to eseg base 
; point to eve addrs. 

; get threshold 

; put it in ax reg. 

; compare eve to thr 
; it no new msg, wait 
; else return 
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c. 



ICADEOFF.PLI 



Prog Name 
Cate 

Hritten by 
For 

Adviser 
Purpose 



LOADBUFF.PLI 
3 1 May 83 
Todd 8. Kersh 

Thesis (AEGIS Modeling Group) 

Professor Kodres 
This module is part of rhe Sratic Model 




commcE memcry buffer. 
V 



load_fcuff€r: pr oced ure (time_^in) ; 



declare 

time in fixed, 
send”mess entry, 
builc_cmH_mess entry 



declare 

sratus fixed binary (15) static init(O), 
sect fixed binary(7) , 

word count fixed binary (15). static init (256) , 
mem Bit(16) static in it ( ’ 5500' b 4) , 
msb bit(16) static in it ( ' OOOe' b4) , 
trade fixed binary (15) , 
head fixed binary!/) , 

rdw wrt bir/16) static init (' 1 0 10 ' b4) ; 

"10 10" means the SEMeX will read the 
hard disk and write to com. mem. buffer. */ 



(bit (16), fixed 
fixed binary 
fixed binary 
bit (16) , bit 
fixed binary 



binary (15) , 

15) , ‘ 

l\f fixed binary (7) 



16 

15 



9 



head = 0 ; /* this sets head to "D" drive */ 

/* This determines the sector based on 39 sectors/track */ 

sect = 1 + mod(tims_in,4 0) ; 

/* This determines the track */ 

track = 1 + trunc (time_in/39) ; 

/* Max tracks available on the REMEX is 210 
therefer, to prevent running out of memory...*/ 

if track > 210 then do: 

put skip list ('The database store is full.'); 
put skip list 

(' This run is recorded as ',time_in,' delta_ts. ') ; 
put skip list 

(' To create a longer run, change the value of dslta_t.'); 
return; 
end ; 

/* This procedure builds the command message 
required for the Eemex Data Warehouse to write the 
data tables located in the buffer corresponding 
to the value of ' time_in ' */ 

call build cmd mess 

(r dw__ wrt, St at us, track, head, sect, mem , msb, word_count) ; 

/* The procedure sends the command message to the 
Remex Data Warehouse to perform the required 



writs operation ♦/ 
call send mess; 
end load tuffer; 
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D 



XF£B.i86 



Prog Name 
Da*e 

Written by 
For 

Advisor 
Purpose 
the ccffliDcn 
0E000:5646 



: XFER.A66 
: 8 June 83 
: Todd B. Kersh 

: Thesis (AEGIS Modeling Group) 

: Professor Kodres 

: This module will transfer a output msg.f 
memory buffer to the oommon memory locatio 
to be read by the Track Processing Module. 



Data 



Code 



cseg 

public 



xf er_msg 



xfer_msg: 
push di 
push si 
push ss 
push ds 
push ax 
puskf 

mov ax,0e000h 
mcv 6S,ax 
mov si,C5500h 
mcv di/06055h 
mov CX.5 



move_msg: 

mov ax,es:rsi] 
mcv es:[dij,ax 
inc si 
inc si 
inc di 
inc di 

Iccp move msg 

pcpf 

pop ax 

pep ds 

pep as 

pep si 

pep di 

ret 

end 



; get common mem. base 
; assign to eseg 



; set loop ctr to 
; pass 5 words 
; (one tbl_8) . 

;load word from buffer 
;stora word into msg. 

; get next word loc. 

; get next word loc. 

;loop until done 
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0 li 



E. 



DISPllY.PLI 



Frog Name ; DISPLAY.FLI 

Date : 8 June 83 

Written by : Todd B. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodres 

Purpose : This will display the status of the tesr 
simulation for the RSP Static Model, and allow the 
user to make measurements to determine the speed of the 
NPS SPY-1A Model execution, 

♦/ 



display: procedure (time); 

decl?.r€ 

time fixed, 

endtime fixed external; 



/♦put listjfascii (26) , 
put skip list (' === 

put skip (2) ; 
put skip list ('TIME;' 



ascii (30) );♦/ 

RSP STATIC MODEL SIMULATION ===' 
,time, ' ENDTIME en dtime) ; 



end display; 



69 



1 


ADV1 


E7C 


.A86 




Pro 


g Na 


me 


; ADV1EVC 


. A86 


Dat 


6 




: 8 J une 


83 


Wr i 


tten 


rr 


: Todd B. 


Kersh 


For 




; Thesis 


(AEGIS 


Adv 


isor 




; Profess 


cr Kodr 


Pur 


pcse 




; This module wi 


Sig 


nal 


Fro 


cessor se 


nding a 


SPY 


- 1A 


Cct 


roller Mo 


del. 



Modelling Group) 
es 

11 simulate the Radar 
new data msg to the 



Data 



Cede 



cseg 

public advance_evc1 



advance evcl: 



pus's es 
push di 
push ax 
mev ax,0e000h 






mev es,ax 


; get com. 


mem. 


mov di,06055h 


; point to 


evcl 


mev ax,€s; [ di] 


; get value 


val 


inc ax 


; increment 


mev €s:[di],ax 

pop ax 

pep di 

pop es 

ret 


; store evcl 





end 



base 



ue 



to 



es eg 
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A£2MSix c 

COMHON ASSEMBLY LANGUAGE LISTINGS 



A. B1DMESSG.A86 



Prog Name : BLDMESSG.A86 

Date : May 83 

Written ty : Toad B. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodres 

Purpose : This primitive module is a general 

command msq. passing routine to the Remex Data 
Warehouse to be used for both Write and Read 
operations. It experts to aet parameters as 
follows from the calling Pit program: 

build cmd mess (word 0, word 1, word 2 , 

“ word 3 high byte, word 3 

low byte, word 4, word 5, 
word 6) 



Data Segment 



6seg 










CCMMEM 


EQU 


OEOOOH 


ESEG 










CRG 5400H 






PUBLIC 


STATUS 








MODIFIERS 


RW 


1 




STATUS 


RW 


1 




TRACK NO 


RW 


1 




BEAD ^ECT 


RW 


1 




MEM SDDR 


RW 


1 




MSB" 


RW 


1 




WORD CNT 


RW 


1 



Code Segment 



CSEG 

PUBLIC EUILE_CMB_MBSS 

BUILD CMD MESS: 

■ PUSH ES 
PUSH CX 
PUSH SI 
PUSH BX 
PUSH AX 
PCSHF 

MOV AX,COMMEM 
MOV ES,AX 
CLD 

MOV SI ,[ BX] 

LCDS AX 

MCV MODIFIERS, AX 
ADD EX,0 2H 
MOV SI ,[ BX ] 

LODS AX 



set source index to point 
; to 1st parameter. 

; AX = para 1, SI incremented 
; to pornt to next parameter. 

; point to next parameter address 
set source index to 
; point to next para. 
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END 



MCV 


STATUS , AX 


ADD 


BX , 0 2H 


MCV 


SI,[ EX] 


LCDS 


AX 


MCV 


TRACK NO , AX 


ADD 


EX , 0 2H 


MOV 


SIr[BX] ; 


LCDS 


AL 


MCV 


AH ,AL 


ADD 


EX , 0 2H 


MCV 


SI ,[ EX] 


LCDS 


AL 


MOV 


HEAD SECT, AX 


ADD 


BX, OlH 


MOV 


SI ,[ BX] 


LCDS 


AX 


MCV 


MEM ADDR,AX 


ADD 


BX,U2H 


MCV 


SI , [ EX ] 


LCDS 


AX 


MCV 


MSB. AX 


ADD 


BX , (5 2H 


MOV 


SI ,[ BX] 


LCDS 


AX 


MCV 


WORD_CNT , AX 


POPE 




POP 


AX 


FOP 


BX 


ECF 


SI 


POP 


CX 


FCP 


ES 



; point to n<=xt parameter 
;set source index to point 
; to next para . 



; point to n axz parameter 
set index to poinr to next 
; get byte para in al rea 
; move al to ah 



;word is now complete for 

; point to next parameter 
;set source index to 
;point to next para. 



; point to next parameter 
;set source index' to 
;point to next para. 



; point to next parameter 
;set source index to 
;point to next para. 



8ET 



address 

address 
para . 

move men 
a ddres s 

address 

address 
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E. S»DHESS1,A86 



Prog Naii€ : SNDMESS1.A86 

Date : May 83 

Written by ; Toad B. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodres 

Purpose ; This primitive module sends the command 
message located in common memory at 0E000:5000 to the 



Remex Data Warehouse for execution, 
status Word in the msg. for successful 



checks the 
msg completion. 



Data Segment 



fcsEG 



RDW ERROR 


DB 


1 






EDW"EESULT 


DB 


1 






RDW"EIR 


DB 


1 






SUCCESS 


EQU 


1 


;code for opn 


succ 


FAILURE 


EQU 


0 


;code for opn 


fail 


RDW READY 


EQU 


08H 






TRIES 


EQU 


05 


; constant 




; RDW interface 


contr oil 


er ports ==> 




SdW CME REG 


EQU 


70H 






RDWSTATUS REG 


EQU 


71H 






REW"ADDE LU 


EQU 


72H 






REW" AD EE" HI 


EQU 


73H 







ESEG 

EXTBN 



CSEG 

PUBLIC 



STATUS :WORE 



Code Segment 



SEND MESS: 



SEND MESS: 

■PUSHF 
PCSH AX 
POSH ES 
P G en c X 
MCV AX,0E000H 
MCV EX ,AX 
MCV CX,TRIES 
SEND RDW MESS: 

“INliL.RDW STATUS REG 
AND AL,RDT? READY" 



;init. loop counter 



CMP 

JNE 

MOV 

CUT 

MOV 

OUT 

MOV 

CUT 

CHECK RDW 

lev 

CMP 

JE 

CMP 



AL,08H ; 

SEND REW MESS 
ALJCH “ 

RDW CME REG,AL 
AX ,U54 0UH 
RDW ADER LO,AL 
AL,IH 

RDW ADER HI,AL 
RESULT:" 

IX ,STAIUS 
AX , SUCCESS 
RDW SUCCESS READ 
AX,FAI1URE " 



; check if interface ready 
;to process cmd packet... 
;ready? 

; if not repeat 

;load extended address 
;offset of packet 
;transfer low byte 

;transfer high byte 

;read status word 
;check for success 

check for failure 
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U) w 
u) n 
a* p 



JNE BDW EETEY 
JKPS CHECK EDW RESULT 
BDW EETEY: 

” MCV BDW ERECR,AL ;save error code 

MCV STATUS, 0 ;clear sratus word 

LOOP SEND BDW MESS ;loop if counter <> 0 

MOV EDW RESULT, OFFH ; return failure code 

JMPS RDTJ EXECUTE EET 
RDW SUCCPS<^ RETD* ~ 

~ MCV HEW RESULT, OOH ;return success code 

EDW EXECUTE EET : 

■ POP CX~ 

PCP ES 
POP AX 
POPE 
RET 

END 
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APPENDIX D 

SPY-1 A MODEL SIMOLATION PROGRAM LISTINGS 



A. SPYTEST.PLI 



/* 

Prog Name : SPYTEST.PLI 
Date : 8 June 83 

Written by : Todd B. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodres 

Purpose ; This is a test module that simulates the 
operation of the NPS SPY-1A Model. It will update the 
tabl 58 data in comiacn memory upon the event count update 
from“the Static Model, after a delay loop that simulat 
the cperaticn of the Track Processor and Radar Schedul 
V 



spy_t€st: procedure; 



declare 

init entry, 
advance evc2 entry, 
threshold fixed bin(15) static 
awaiti entry (fixed binary (15)) 
i fixed bi nary (15) ; 



init (1) 



9 



/* This will initiate the eventcounts to 0 */ 



call init; 
do while (' 1 • b) ; 

call advance evc2; /* This simulates sending a new 
” dwell cmd. msg. */ 

call await 1 (t hreshold) ; /* wait for results 

e.g. tbl_3 V 

/* This is a delay loop simulating SPY-1A Model 
processing time. »/ 

threshold = threshold + 1; 



do i = 1 to 50; 

put skip listC SPY-1 IS PROCESSING DATA...'); 
end ; 

end; /* while */ 
end spy_test; 
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(D (D 
li (n 



E. IHIT.A86 



Prog Name 
Date 
Written 
For 

Advisor 
Purpose 



by 



INIT. A 
1 9 Jun 
Todd B 
Thesis 
Prof es 
This m 



memory locations fo 



86 

€ 83 
. Kersh 
(AEGIS 
scr Kod 
cdule i 
r the e 



Modelina Group) 
res 

nitiates the 
ventcounts to 0. 



Data 



Is 



eg 



eseg 

public evc1,evc2 
ora 0 



org 06 0 2 Oh 
evc2 rw 1 

evcl rw 1 



Code 



cseg 

public 



init 



inir 



push 



ax 

es 



mev 


ax , OeOOOh 






mev 


es,ax 


;set 


exeg 


mev 


ax ,0 


;set 


ax t 


mo V 


evcl, ax 


;s€* 


even 


mev 


evc2, ax 







end 



to 0 



pep 

pep 

rer 



c 5 

ax 



mem 
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C. ABAIT1.A86 



Prog Name : 
Date 

Written ty : 
For : 
Advisor : 
Purpose : 
been updated 
Radar Signal 



AWAIT1 .A86 
8 June 1983 
Todd B. Kersh 
Thesis 

Professor Kodres 

This module checks to see if an eve. has 
at 0E0C0:5616 of common memory by the 
Processor Simulator. 



Data 



iseg 



eseg 

extern evc1:word 



Cede 



cseg 

public awaiti 

await 1 ; 

push si 
push ax 
push es 
mov ax,0e000h 
mev es,ax 
mov si, [ bx ] 
Icds ax 
poll : 

emp ax, eve 1 
jnz poll 
pep es 
pop ax 
pep si 
ret 

end 



; get com. mem base in eseg 
get parameter - threshold 
; load it in ax reg. 

; compare eve to threshold 
; if ho new message sent, wait 
; else, return 
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aDV2EVC.A86 



Prog Nams : ADV2EVC.A86 

Date : 19 June 83 

Written by ; Todd E. Kersh 

For : Thesis (AEGIS Modeling Group) 

Advisor : Professor Kodres 

Purpose ; This icdule will simulate rhe Radar 
Scheduler sending a new dwell command to the RSP. 



Data 



is3< 



eseg 

extrn evc2:word 



Code 



cseg 

public Advance_evc2 



advance evc2: 
pusTi es 
push ax 

mcv ax,0e000h 

mov es,ax ; get addr. of comm. mem. 

; in eseg 

inc evc2; advance eventcount 
pop ax 
pop es 
ret 

end 



base 



78 



APPENDIX E 

CBJECT-OBIENTED DESIGN OF THE DYNAMIC MODEL 

A. DEFINE THE PROBLEM 

A system is required that will interface with existing 
SPI-1A Badar Controller modules and simulate the Signal 
Processor of the Radar. The required interface will actu- 
ally include the Radar Output Module and the Radar Return 
Module, and the Beam Stabilization Modules. The Signal 
Processor Simulator must contain a database representing the 
environment the Radar will probe for target tracks. The 
database must be user changeable at any given time during 
the operation (i.e. add target tracks, delete target tracks, 
and change target tracks) so that the logical operation of 
the SPY-1A Radar Modules (Radar Scheduling and Track 
Processing) can be tested and explored. 

B. DEVELOP AN INFORMAL STRATEGY 

The database for the signal processor will capture the 
informaticn for each target at discrete time intervals 
needed tc define it's position. The information maintained 
about each target track will include it's actual position 
(x,y,z,r) and it's acceleration components (ax,ay ,az,ar) at 
a discrete time interval (t) . Interaction operations that a 
user may request include - initiation of a target track over 
a range of time (Ti --> Tn), deletion of a previously 
entered target track throughout all or part of it's initi- 
ated range of time, and changing a previously defined target 
track at any time during it's pre-defined time range. The 
user will also be able to start and stop the simulation at 
any time. The user will have a two dimensional display of 
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the radar environment with current tracks and relative posi- 
tions symfcclized during the simulation. A status report of 
current targets will be available while in a non-running 
mode tc assist the user in the environment definition. 

C. FOBUailZE THE STHiTEGT 

• Ide ntif y the Object s a nd their Attributes 

a. SIMULATION^OPERATIONS 

b. TRACK_DATA; 

Target Information: 
target_ID 
actual_ position 
acceler ation 
time 

2 • Ide nti fy O per ation s on the Objects 

a. SIMOLATION_OPERATIONS 

b. DISPLAY: 

Start 

Stop 

C. TEACK_DATA: 

Sta tus^Repcr t 
Quit 

Target_Infor mation : 
create 
dele te 
change 
Database 
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SIMULATION OPNS- 
( subprogram ) 



SIMULATION OPNS 

(packager 

create tgt 
dele te~tg t 
change""tgt 
stat us"r pt 
quit 



+ 

( 

V 

DISPLAY 
(package) 
start 
stop 



TRACK DATA 

> (package) < 

+ + + 

I I 

TGT INFO DATABASE 

(package) (package) 

tgt record acti ve_records 

“ data 



) 

I 

•+ 



Figure E. 1 Object-Oriented System Graph. 



^ • Cede the Pa ckage Specificat ions in Ada 



package TRACK DATA is 
package t5t_INF 0 is 

end TGT_INFO; 

package DATABASE is 

end EfiTAEASE; 
end TRACK_DATA; 

package TGT INFO is 

type END TIME is constant := 1000; 
type COORDINATES is (X,Y,Z,R): 
type ACCEL VECTORS is ( AX , AY , AZ , AR) ; 
type EISCRI:tE_TIME is range .. END TIME; 
type TARGET is record ” 

LCCAHON : COORDINATES: 

ACCELERATION: ACCEL VECTORS; 

TIME : DISC RETE_TIME ; 

end record; 
end TGT_INFO; 
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package DATABASE is 
use TGT INFO; 

MAX RECORDS : constant := 20; 

type RECORD INDEX is range 0 .. MAX RECORDS; 

type TRACK ■RECORDS is array ( REC02D~INDEX) of TARGET; 

ACTIVE TGTS : RECORD INDEX; 

DATA ~ : TRACK “SECORDS; 

end DATABASE; 



with TRACK DATA; 
use TRACK'EATA; 
package SIHOLATICN 
type OPERATION 



OPNS is 

is (CREATE TGT, DELETE TGT, CHANGE TGT, 
STATDS“RPT,QUIT) 
function GET return OPERATION; 
procedure CREATE TGT; 

’ DELETE“TGT; 

CHANGE"TGT; 

STATUS"RPT; 

QUIT: 



procedure 

procedure 

procedure 

:rocedure 



end SIMUIATICN_OPN§ ; 

with TRACK DATA; 
use TRACK“EATA; 
package DI"SPLAY is 

type CONTROL is (START, STOP) 
function RUN return CONTROL; 
procedure START; 

E rocedure STOP; 

ISPLAY; 



Further programming would design and build the subprograms, 
functions, and procedures defined by these package 
specifications. 
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AP PENDIX F 

SIGNAL PROCESSOR MODEL OSERS HANOAL (7ER.1.0) 

A. GENERAL 

This manual is for use with the NPS AEGIS Modeling Group 
AN/SPY-1A Radar Controller Model: Signal Processor 

Emulation version 1.0. It does not explain the structure of 
the modules that make up the program, only it’s functional 
components and how they might be utilized to test the SPY-1A 
Model. For further information about the program design and 
implementation, see Kersh,T.B., Signa, ! Proces sor Int e rf ac e 
Simu lation of ^e AN/SPY -1 A R ada r C ontrolle r, Masters 
Thesis, Naval Postgraduate School, Monrerey California 1983. 

The manual is divided into the two major functional 
areas: developirg the target database to be stored in the 
REMEX Data Warehouse, and running the static Model of the 

Signal Processor against a simple SPY-IA simulator. It will 
be assumed that any potential user of this system is 
familiar with the boot procedure for the Remex Data 
Warehouse disk system. Assuming the user has booted from 
the REMEX B: drive and logged into the REMEX D; drive, place 
the Signal Processor system disk in the C: drive, and type: 

D>C:RSP <retrrn> 

At this point the Signal Processor Emulation System will 
load and the remaining database development and model opera- 
tion will be menu driven. 

The following functions are available within the Signal 
Processor Interface simulation - 
TARGET BAIAEASE: 

1. CREATE the inital target-list and initial database. 
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2. DELETE any targets at any specified descrete rime. 

3. CHANGE the parameters of the parametric equations 
representing the target tracks at any specified 
descrete time. 

4. FBINT the current target-list zc rhe terminal screen 
cr the printer at the specific descrete time repre- 
sented by the target-list. 

SIMULATICN: 

1 . BUN will execute the Static Model in a test environ- 
ment to be used for testing the Signal Processor 
Interface Simulation System. 

After development, the user can document the targets 
contained in the target- list at a particular descrete time , 
so that he has a hard-copy record of rhe trend of his data- 
base. This feature will be important in determination of 
the effect of different target combinations and densities on 
the SPY-1A Controller Model. The Signal Processor Interface 
Simulation Target-Database development system should be 
usable in ccnjuction with other testing systems devised by 
future AEGIS Group members for the logical testing of the 
SPY- 1 A system. 

E. CCNSTBOCT TARGET DATABASE 
1 . Main Menu 

Just prior to the display of the main menu, the 
program will ask for user input defining the descrete time 
intervals to be used for the update of the buffer used by 
the Target-Database system. The ratio of dwell commands 
received from the Radar Schedular Module to the target- 
tuffer update, multiplied by the actual turnaround time of 
the SF-1A Controller Model will be the real-time achieved by 
the system. The user may assign values from .1 to 1 to this 
ratio value. The next question asked of the user is how 
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long th= siculation will run. The maximum possible length 
is dependent on the storage space available on the REMEX 
Data Warehouse, and the time is based on the average assumed 
dwell command interval time received from the SPY-1A Radar 
Controller Model. To determine the simulation run limit in 
terms of descrete time increments, one must realize that 
each descrete time increment is in one-to-one correspcndance 
with the sectors used to record the database on the REHEX. 
Therefore, since there are 39 sectors per track, and 210 
tracks available for use, there are 8190 available descrete 
time intervals available for a simulation run. The real-time 
length for the simulation run is then dependent on the 



♦♦♦ MAIN MENU 



What course of action do you wish? 

(1) CREATE a database of tracks 
(you must do this first) 

2) DELETE a track from the database 
3' CHANGE a track on the database 
4) PRINT the current target list 



After a database is satisfactory you may: 

(5) RUN a simulation 

(insure the rest of the SPY-1 Model is setup) 

(6) QUIT and return to the operating system 
(enter 1-6 and <cr>) ; 



Figure F. 1 Signal Processor Emulation Main Menu. 



descrete time ratio. Assuming a negligible time for 

updating the target buffer from the REMEX, and a turnaround 
response time from the SPY-1A Controller Model of .001 
seconds, if a ratio of "1" were chosen, the maximum time 
available for a simulation run would be; 
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1. "1” second = .001 sec. * 1000 (or 1000 dwell commands 
issued per buffer update) 

2. since the target-buffer is updated once every second, 
there are 8190 seconds of maximum simulation time 
available . 

The next item appearing on the screen is the Main 
Menu. The first thing required is to build a database in 
the REMEX Data Warehouse. To do this, the user will 
initially pick choice (1) CREATE. After initializing his 
Database, the user be able to move forward in descrete time 
and delete target tracks completely, or just change the 
paramereis cf the track. It is suggested that the user use 
option (4) PRINT after each iteration of nhe previous two 
options and after CREATE, to mainrain a record of the modi- 
fications made on the database. When the user has finished 
with his Target Database, he may request to (5) RUN a Static 
Model simulation. In this mode the SPY-1 A Controller Model 
Simulator ’'SPYTEST” is designed to test the Static Model. 
Further instructions on the use of this option are discussed 
in Section C. Of course, at any time after the user has 
returned to the Main Menu, he may choose option (6) QUIT to 
return to the operating system. 

2. Cre ate Database 

To use the Signal Processor Interface Simulator, a 
Target-Database must first be constructed. A Target-List, is 
used which contains target data to construct a 

Target-Database. The parameters used to set up the 
Target-List for each target are the constant values used in 
the parametric equations shown in Figure F.3 These parame- 
tric equations derive from Boone, N.A., A Multimi cr opo c essor 
Appr oach to si mul ate I/O for the AEGIS A N/SPY - 1 A Rada r 
Controller, Masters Thesis, Naval Postgraduate School, 
Monterey California, 1981. Boone's work concerns the 
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=== CEEATE TARGET MODULE === 

Initiate target # 

Parametric Equations? {1,2, 3, or 4): 

X_range (a)? (-256 ,+2 5o) nm : 

Y range (uj? (-256 ,+2 56) nm: 

X velocity (b) ? (-32, +32) m/secT 
Y_velocity (v) ? (-32, +32) m/sec: 

X acceleration (c) ? (-. 0 15625, + .'015625) m/sec/sec: 

Y acceleration (w) ? {-. 0 156 25 , + . 0 1 56 25) m/sec/sec: “ 

Zlaltitude (d) ? (0,20000)ft: 

create more targets? (Y or N) : 



Figure F.2 CREATE Function Menu. 



( 1 ) 

( 2 ) 

( 3 ) 

(^) 




a + 
u + 
d 



b*t 

v*t 



c*t*t 

w*t*t 



a + b*t + c*t*t 
u + v*sin (w*t) 
d 

a + b*cos (c*t) 
d 



X 




= a + 


b*cos 


(c*t| 


y 




= u + 


v*s in 


(w*t) 


z 


t 


= d 







Figure P.3 Parametric Equations. 

simulation of the AEGIS Command and Decision functions, and 
these equations were utilized to maintain compatiblity 
throughout the Model. After defining the parametric equa- 
tion for the first target, rhe user may choose to define 
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further targets and will be prompted similarly as previously 
shown. When he is satisfied that the target-list is 

complete, he may indicate that no more targets are to be 
created, and he will te returned to the Main Menu. At than 
time it is recommended that the user request a PRINT of the 
initial target-list for future reference. 

3 • Delete Targets 



=== DELETE TARGETS MODULE === 

WHAT TARGET DC YOU WISH TO DELETE? ' 

(TGI. NOM. RANGE 1- ): 

I 



Figure F.4 DELETE Function Menu. 

Frier to the Delere Menu, the user will be asked "At 
what time do you want to delete a target?”. The user is 
being asked to define the descrete time within his previ- 
ously defined range of descrete time that he wishes to 
delete a previously defined rarget. It is important tha-^ the 
user have developed a plan for target modifications based on 
his defined descrete time range, since the Targe r- Database 
development routine will not allow one to recover deleted 
targets. After answering the time question, the Delete menu 
will be displayed, and the target list appropriately 
updated. After Deleting a target, the user will be prompted 
to "continue (Y/N) ?” . He may answer Y (es) to delete more 
targets or N (o) to return to the Main Menu. 
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^ • Cha nge T ar qets 

The Change choice from the Main Menu will first 
prompt the user requesting what time he wants to change a 
target, within his predefined descrete time range. After 
answering, the user will see the Change menu (see Figure 






=== CHANGE TARGETS MODULE === 

WHAT IS THE TARGET NUMBER YOU WISH TO CHANGE? 
(TGT.NUM. RANGE 1- ) : 

WHAT DATA ITEM IS TO BE CHANGED? 

(1) PARAMETRIC EQUATION 

(2) EQUATION PARAMETERS 

(if the choice is one, then:) 

WHAT IS THE NEW EQUATION NUMBER (1-4)? 

(if the choice is two then:)^ 

WHAT ARE THE NEW PARAMETERS: 

X_range (a) ? (-256 ,+256) nm: 



Z_alt. (d) ? (0, 200 00) ft: 

(and fcr either choice..) 

DC YOU WISH TO CHANGE ANOTHER TARGET? 



(Y/N) : 




Figure F.5 CHANGE Function Menu. 



F.5). Again, let it be 
have a plan for the cverall 
possible to gracefuly go b 
target database is developed, 
to the user to obtain a print 
you return tc the Main Menu. 



that it is important tc 
database since it is not 
in sequential time as a 
Also, it is again recommended 
of the Target-List as seen as 



e mphasised 
target 
ackwar d 
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C. BON SIAHC MODEL 

The SFY-1A Controller Model Simulator '• SPYTEST .CMD" is 
provided as a tool to test the Radar Signal Processor 
Interface Simulation Static Model. "SPYTEST.CMD” is just a 
simple eventcount and sequencer module. It contains a delay 
loop to simulate the time between the receipt of a "raw 
data" message from the Signal Processor Interface, the 
subsequent processing of the target data, and the resultant 
dwell command message generated to the Signal Processor 



=== RSP STATIC MODEL === 
version 1.0 June 83 



At this point you should have created 
a database and are now ready to run 
the Static Model. 



=== STATIC MODEL MENU === 

(1) TEST run the simulation 

(2) QUIT and return to main menu 
enter 1-2 and <cr>: 



Figure F.6 STATIC MODEL Function Menu. 

Interface. The delay loop is arbitrarily configured at this 
time, and the user should consider contriving a delay that 
more closely represents the turnaround time the SPY-1A 
system should provide. When entering the test mode, the 
user will be prompted to "Load SPYTEST.CMD from another 
system CBT/SEC. When complete, enter "0"<cr> to begin ". 

When the SPY-1 A Controller Simulator has been initiated, 
the Static Model will begin operation after the user has 
typed "0<or>". The display for the Static Model is shown in 
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ESP STATIC MODEL SIMULATION 



TIME : 



ENDTIME: 



j 



Figure F.7 STATIC MODEL Display. 

Fig. F.7, and provides the user with only a minimum ammount 
of information to determine the progress and speed of execu- 
tion for the SPY-1A Model. Since the Static Model and its 
inherent display functions will be part of the timed data 
gathered by the user, it is recommended that the SPY-1A 
Controller Simulator be utilized to measure the Static Model 
time. The measured Static Model run time can be used in 
future rur-time testing of the NPS SPY-1A Controller Model 
to determine net SPY-1A Controller Model achievable speed. 



91 



LIST OP REFEREHCES 



1. Grant, J.V. Ill, A Multi-Microprocessor Based Modsl of 
the Ae^is AN/SPT£r5"lI21r Con^oTT — RaTar — Sc'Ee'duler 
Prccess, Master's 'ihesxs, Raval 'Postgraduate "School , 
Hcnferey California, 1981. 



2. Cech, J. V., A Multi- Micro proce ss or B ase d Model of the 
Aegis AN/SPYr115 Pad ar Con~roT:~ Trac^ "Processina, 
Haszsr's TTresls, "ITav al Eds rgr adu at e “School, Hon"terey 
California, 198^ 



3. 



Boone , 
Sinulate 
Hasrer'*^ 
Calif cm 



N.A., A Multi m icr o processo r Approach to 
IZO for Fhe ITBGT^IIZI'^ETl-T^adar'JoproIlsrT 
Thesis, davaT 'Pdsrgraduale ^Hdol, donrerey 
ia, 198r 



4. Bocch, G. , Soft ware Engineerin g with Ada, 
Ben jamin/Cummings IricT, 1983. 



5. Riche, R.S. and C.E. Williams, A Software Foundation 
for A N/SPY -1A R ada r Control, Master''’s~TEesIs , daval 
Postgfaduale ScTiddT, donlerey California, 1981. 



6. Almquist, T.V. and D.S. Stevens, Alteration and 
Implem ent ation of the C P/M -86 Ope rating dys lem for a 
duII I- user Env ironme nt 7 “TTasIer''^ Tliasis, Tlaval 

Posf grlduate EcEddT7“donter ey California, 1982. 



7. EX-CELL-0 Corporation, REHEX Technical Manual for Data 
Ware h ous e Mode Is RDW SlEE , EDff T9T9. 



8. EX-CELL-0 Corporation, REMEX Product R efer e n ce M anual 
an d P erf o r ma n ce Speci f icTITons T TETP . 



9. Klinefelter, S.G., Implimentat ion of a Re al-Time , 
D is tr ibu te d 0 pe rat ing "^ysEem for a Multiple ^muufer 
Sysfem, Easier 's" The sis , “davaT Fosfgraduaf e~Sc Hdcl , 
Honlerey California, 1982. 



10. Micropclis Corporation, M icr opol is Specifi cation 

1220 Series Rigid Disk Drive E'uDsvstems, Clafs worth! 
dallfcfniaT Td'SUT 



11. Digital Research Corporation, C P/M-8 6 Op er ating 
Sy^ems G uid e , 198 1. 



12. Digital Research Corporation, PL/I-86 Manual, 1983. 



92 



INITIAL DISTRIBOTION LIST 



No. Copies 

1. Defense Technical Information Center 2 

Caraercn station 

Alexandria, Virginia 22314 

2. Defense Logistic Studies Information Exchange 1 

U.S. Army Logistics Management Center 

Fort Lee, Virginia 23801 

3. Library, Code 0142 2 

Naval postgraduate School 

Mcntery, California 93940 

4. Department Chairnan, code 52 2 

Deoartment of Computer Science 

Naval Postgraduate School 
Monterey, California 93940 

5. Professor Ono R. Kodres , Code 52Kr 2 

Department of Computer Science 

Naval Postgraduate School 
Monterey, California 93940 

6. Captain Brad Mercer, OSAF, Coda 52Zi 1 

Department of Computer Science 

Naval Postaraduate School 
Monterey, California 93940 

7. CPT Todd B. Kersh 2 

HCi U.S. Army CECCM 

ATTN: DRSEL-TCS-CB 

Fort Monmouth, New Jersey 07703 

8. RCA AEGIS Data Repository 1 

RCA Corporation 

Government Svstems Division 
Mail Stop 127-327 
Moorestown, New Jersey 08057 

9. Library (Code E33-05) 1 

Naval Surface Warfare Center 

Dahlgren, Virginia 22449 

10. Daniel Green (Code N20E) 1 

Naval Surface Warfare Center 

Dahlgren, Virginia 22449 

11. Curricular Officer, Code 37 1 

Computer Technology Curricular Office 

Naval Postgraduate School 
Monterey, California 93940 

12. Dr. K.J. Gralia 1 

Applied Physics Laboratory 
Johns Hopkins Road 
Laurel, Maryland 20707 

Dana Small 
Code 8242, NOSC 
San Diego, California 92152 

93 



13. 



1 



14 



1 



. CET Mark R. Kindi, D.S.A. 

413 E. Washington St. 

Villa Park, Illinois 60181 

15. Dr. Bert Y. Kersh 1 

260 Sacre Lane 
Mcnmcuth, Oregon S7361 



94 



w, 






i 




■* O I . 



Thesis 
K3894 
c. 1 



201684 



Signal processor 
interface simulation 
of the AN/SPY- 1 A rad 
controller. 



r 



5 DEC S$ 



3 0 9 5 5 



Thesis 
K3894 
c. 1 



201G84 



Kersh 

Signal processor 
interface simulation 
of the AN/ SPY- 1 A radar 
controller. 



thesK3894 





